QQ登录

只需一步,快速开始

扫一扫,访问微社区

登录 | 立即注册 | 找回密码
查看: 1811|回复: 0

企业以太坊联盟(EEA)愿景报告Enterprise Eth...

[复制链接]
发表于 2017-3-14 19:05:46 | 显示全部楼层 |阅读模式
   
新成立的企业以太坊联盟(EEA)近日发布了一份愿景报告,概括了“为用户和利益相关方提出、实施并整合以太坊协议进展,以支持企业以太坊协议的愿景。”报告中,EEA讨论了诸多与可插拔共识、治理、互操作性、以太坊协议更新、安全代码执行、存储和性能优化相关的主题。
本愿景报告在以太坊联盟成立活动中发布,正式确定了30个组织机构共同集中研究以太坊企业用例。该联盟不仅包括像微软、摩根大通、因特尔、汤森路透等大型组织,还包括如BlockApps、String Labs和ConsenSys的区块链初创企业。
就眼前来看,EEA确定了2017年的五个目标,包括:
1.开发一个充分模块化的以太坊实施工具,以分离并定义网络层和存储层之间的清晰接口,这是可插拔共识的原型,最大程度减少了切换共识算法所需的代码更改。
2.试验潜在的共识算法,以及数据隐私和许可框架。
3.制定一套满足企业需求的清晰的能力及性能特征,包括:
   a.跨10方网络每秒100笔交易。
   b.高容量及高价值用例。
   c.高可用性/可靠性。
   d.并行化及横向扩展。
4.基于上述知识以及从成员处收集的路线图和要求,制定第1版企业以太坊规范,即提出参考实例。
5.利用健全的治理流程确保方法的调整和一致性。

可插拔共识
共识是区块链内的节点同意交易状态的行为,并且以参与节点一致同意的算法为依据。由于当前以太坊的实施工具不是模块化的,当组织需要向共识算法添加额外的特征时(例如隐私),最终可能会导致以太坊实施工具分叉。分叉的问题在于,这些投资现在难以进行共享及创建碎片。为了满足互操作性这一需求,EEA希望提供基于模块化的共识算法。EEA愿景报告中就明确阐述了可插拔共识如此重要的原因:
常见的模块化实施工具将为企业以太坊规范的制定提供代码库,同时尝试使用联盟共识算法。可插拔共识需要模块化的客户端网络连接接口以及以太坊虚拟机和共识算法之间的接口干净简洁,事实上,正式这些接口实现了共识层的可插拔。
采用模块化方法,EEA虑及的一个因素在于:
这些方法都不是对算法细节的规范,而是根据用例许可采用不同算法。

第1版企业以太坊规范
EEA的目标不仅仅是开发实施工具,而是要发布规范,从而:
通过增加用于整合开发、开发运营和管理工具,以及集成传统系统的API的可用性来加速生态系统的开发。
通过提供规范,供应商能够提供其自身的实施工具,但由于存在互通点,各组织可通过接口专注于他们的特定需求。兼容性和互操作性不仅是企业以太坊的一个目标,也是公有以太坊的目标。

稳健治理
该联盟眼下的目标是成为一家总部设于美国的非盈利基金会。除一名执行董事承担日常管理职能外,该联盟目前正寻找一名主管行政管理人员以及一名志愿主席。
EEA表示其核心团队将主要来自于其成员组织,以及有成员参与的特别利益团体,分别专注于编写原型、架构、路线图和行业团体。这些利益团体将建立在以下4项指导原则的基础上:
1.制定开源标准
2.与创建者及实干者合作开发通用系统
3.保持与公有以太坊的兼容性
4.在数据标准问题上避免重复劳动

注重互操作性
虽然跨区块链协议间的互操作性可能需要一些时间才能实现,但EEA正在构建一组侧重于互操作性的要求,包括:
1.能够在企业以太坊的各个层切换组件,同时保持应用程序可移植性及网络交易
2.能够提供可与核心规范互操作的非标准扩展
3.入站和出站数据接口和EVM挂接
4.公有链兼容性
为实现互操作性,EEA计划使用:
具备清晰接口及API的抽象概念及模块性。
EA同时预计接口一旦发布将难以更改,因此其认为这种互操作性的工作:
即使在项目早期阶段,仍十分关键。

更新以太坊协议
当前以太坊协议取决于节点根据在计算上开销很高的工作量证明(PoW)算法选择用于最长链的下一区块。这种方法的缺点就是区块链每10秒才能够提交一个新的区块,因此有所局限。随着以太坊进军企业届,将服务扩展到数百万用户的能力给现有协议带来了挑战。
EEA正在寻找既能提高可扩展性,同时又能够降低计算成本的PoW替代算法。有许多正在接受评估的方法能够塑造以太坊块共识协议的未来,包括:
委托权益证明
Ouroboros
Casper
权威证明
在以太坊的网络协议层中存在其他机会,其中需要“可能经历拜占庭将军问题的节点网络中状态序列的全序关系的原子广播”。关于以太坊的网络共识协议有几个建议正在考虑当中,包括:
HoneyBadger
HydraChain
Tendermint
结合区块及网络共识协议的一些方法包括:
HydraChain
Ethermint
除了对区块和网络共识协议做出的变更之外,其他诸如水平分区、并行化和状态信道之类的其他可扩展性方法也正在探索之中。

共享数字基础设施管理
企业以太坊通过分布式账本技术(DLT)将各组织结合在一起。而新出现的挑战存在于治理领域。例如,当共享程序或合约需要进行版本控制和更新时会发生什么? EEA正在:
探索共享管理的合约接口和类别的开发,以及适用于已部署系统上的操作代码更新的设计模式。

可信计算及Oracles /数据馈送
保护需要执行的可信代码有几种不同的方法。一种方式是使用主流硬件。这种方法的一个例子即“构建Enclaves并提供内存加密的硅芯片电路的英特尔SGX,在这一模式下,只能运行签名的、经过认证的代码,而其他进程则无法访问。”
解决这个问题的另一种方法是利用像Microsoft Azure的Cryptlets这样的服务,这是微软的Project Bletchley计划的一部分,并致力于提供安全的区块链中间件服务。
当尝试将数据源纳入分布式应用程序或智能合约中时,运行受信任代码的安全位置非常重要。以太坊企业计划试图通过以下方式解决安全代码执行问题:
最初将侧重协议层面的实施,随着时间的推移,基金会成员机构有望围绕oracle数据建立有意义的设计模式(或许更重要的是,如何对发布恶意数据的不良行为者实施惩罚)。

存储
许多去中心化的应用具有存储数据(例如文档及媒体)的要求。当前,区块链不是存储此类型数据的成本有效或高效的方式。因此需要一种在链外安全地存储该数据的方法。企业以太坊联盟也提供了一些计划(如IPFS和Swarm)尝试解决这一问题。

性能改善及优化
目前以太坊区块链每秒能够处理几十笔交易。在企业背景下,组织将根据不同的用例提出不同的要求。倘若考虑到地理位置的灵活性,在变更的连接上提供所需的交易数量就十分必要。 为了满足企业的此类需求,EEA正致力于开发以下性能特点:
1.基于特征的各种已识别的参数化来规定可用基准
2.简述客户端如何能够测量各种类型的性能
3.相关参数:
   a.节点连通度
   b.最佳网络拓扑(连接的数量和模式)
   c.连接的可靠性(维护节点之间的连通度)
   d.失败情况:节点间停止彼此交流时
   e.安全
   f.活跃度
   g.正确操作所需最少数量的运作良好的诚实节点
   h.交易最终确认时间
   i.网络节点总数
   j.节点拓扑
   k.传输时间方面的节点间距离
   l.同步/异步消息传递
   m.每秒工作量的交易数
   n.交易/区块传输和处理延迟
                                        The newly formed Enterprise Ethereum Alliance (EEA) has published a Vision Paper outlining “a vision for users and stakeholders to propose, implement, and integrate advances to the Ethereum protocol with support for Enterprise Ethereum protocols.” In this paper, the EEA discusses many topics related to Pluggable Consensus, governance, interoperability, Ethereum protocol updates, secure code execution, storage and performance optimization.
This Vision Paper was released in conjunction with the Enterprise Ethereum Alliance launch event which formalized 30 organizations coming together to focus on enterprise use cases of Ethereum. The alliance includes large established organizations like Microsoft, J.P. Morgan, Intel, Thomson Reuters and blockchain startups like BlockApps, String Labs and ConsenSys.
In the short term, the EEA has identified five goals for 2017, including:
  • Develop a sufficiently modular Ethereum implementation to separate and define clear interfaces between networking and storage layers - that is a prototype for pluggable consensus that minimizes the code changes required to switch consensus algorithms.
  • Experiment with potential consensus algorithms, along with data privacy and permissioning frameworks.
  • Develop a clear set of capabilities and performance characteristics that suit the needs of enterprises, including:
    • 100 transactions per second, across a 10 party network
    • High volume and value use cases
    • High availability/reliability
    • Parallelization and horizontal scaling
  • Develop a Version 1 specification for Enterprise Ethereum, based on the learnings from the above plus the roadmap and requirements gathered from members, i.e., produce a reference implementation.
  • Leverage a robust governance process to ensure alignment and agreement on approaches

Pluggable Consensus
Consensus is the act of nodes, within a blockchain, agreeing on the state of transactions and is predicated upon an algorithm that participating nodes agree. Since current Ethereum implementations are not modular, when organizations need to add additional features to consensus algorithms, for example privacy, they may end up forking the Ethereum implementation. The problem with forking is that these investments are now difficult to share and create fragmentation. In order to address interoperability needs, the EEA is looking to provide modular based consensus algorithms. The EEA Vision Paper describes why Pluggable Consensus is important:
A common, modularized implementation will provide a code base for developing the Enterprise Ethereum specification and also experimenting with consortia consensus algorithms. Pluggable consensus needs a modularized client with a clean interface for networking and between the Ethereum Virtual Machine and the consensus algorithm - it is really these interfaces that make the consensus layer pluggable.
One consideration the EEA is allowing for, with a modular approach, is they are:
not being prescriptive as to the specifics of the algorithm, but rather should enable various algorithms to be used dependent on the use case.
Version 1 Enterprise Ethereum Specification
A goal of the EEA is not solely to develop an implementation, but rather to publish a specification in an attempt to:
accelerate ecosystem development by increasing the availability of APIs for integration with development, devops and management tools as well as legacy system integration.
By providing a specification, vendors can provide their own implementations, but because there are interoperability points, through interfaces, organizations can focus on their specific requirements. Compatibility and interoperability is not only a goal with Enterprise Ethereum, but also with public Ethereum.
Robust Governance
The alliance is currently targeting being a US-based not-for-profit foundation. The alliance is looking for a lead executive and volunteer Chair, in addition to an Executive Director, to take on the day-to-day management functions.
The EEA has stated its core will be based upon members and member participation with special interest groups focused on writing prototypes, architectures, roadmaps and industry groups. These interest groups will be grounded in four guiding principles:
  • Development of open source standards
  • Working with builders and doers towards a general purpose system
  • Maintain compatibility with public Ethereum
  • Not reinventing the wheel on data standards
Emphasis on Interoperability
While cross blockchain protocol interoperability may take some time to be realized, the EEA is building a set of requirements focused on interoperability including:
  • Ability to switch components at various layers of the Enterprise Ethereum while maintaining application portability and network transactions
  • Ability to provide non-standard extensions that are interoperable with the core specification
  • Inbound and outbound data interfaces, and EVM hooks
  • Public chain compatibility
In order to achieve interoperability, the EEA is designing using:
abstraction and modularity, with clear interfaces and APIs.
The EEA also anticipates that interfaces will be difficult to change once published, and as a result sees this interoperability work to be:
critical, even at these early stages.
Updating the Ethereum Protocol
The current Ethereum protocol is dependent upon a node choosing the next block for the longest-chain based upon a Proof of Work (PoW) algorithm which is computationally expensive. The downside to this approach is that there is a limitation of a blockchain being able to commit a new block around every 10 seconds. As Ethereum make more inroads into the enterprise, the ability to scale services to millions of users creates challenges for the existing protocol.
The EEA is looking for alternatives to PoW that improve scalability and reduce computational costs. There are many approaches being evaluated which may form the future of Ethereum block consensus protocols, including:
  • Delegated Proof of Stake
  • Ouroboros
  • Casper
  • Proof of Authority
Other opportunities exist in the network protocol layer of Ethereum where “atomic broadcasts of a total order of state sequences amongst a network of nodes that may experience byzantine failures” are required. There are several proposals of network consensus protocols for Ethereum being considered, including:
  • HoneyBadger
  • HydraChain
  • Tendermint
There are also some approaches that combine both block and network consensus protocols, including:
  • HydraChain
  • Ethermint
In addition to changes to block and network consensus protocols, other scalability approaches like sharding, parallelization and state channels are also being explored.
Shared Digital Infrastructure Administration
Enterprise Ethereum brings organizations together through Distributed Ledger Technology (DLT). One emerging challenge is in the area of governance. For example, what happens when a shared program, or contract, needs to be versioned and updated? The EEA is looking to:
explore the development of contract interfaces and classes for shared administration, in addition to design patterns applicable to the updating of operational code on already deployed systems.
Trusted Computing and Oracles/Data Feeds
There are a few different approaches to secure trusted code that needs to be executed. One such way is through the use of mainstream hardware. An example of this is “Intel SGX which provides enclaves, memory-encrypted on-silicon circuits which can only run signed, attested code, in a way such that other processes cannot access it.”
Another way to approach this problem is to leverage services like Microsoft Azure’s Cryptlets which is part of its Project Bletchley initiative and focuses on providing secure blockchain middleware services.
Secure locations to run trusted code is important when trying to include data feeds into distributed applications, or smart contracts. The Ethereum Enterprise initiative is trying to address secure code execution by:
focusing on protocol level implementations at the onset, with time, efforts to establish meaningful design patterns around oracle data (and perhaps more importantly, how to apply penalties for bad actors publishing malicious data) are expected to emerge from members of the Foundation.
Storage
Many decentralized applications have requirements to store data such as documents and media. Currently, the blockchain is not a cost effective or efficient way to store this type of data, thus requiring a way to securely store this data off-chain. There are a couple initiatives such as IPFS and Swarm trying to solve this problem.
Performance Improvement and Optimization
Currently the Ethereum blockchain is able to process tens of transactions per second. In enterprise settings, organizations will have different requirements depending upon their use cases. Providing flexibility that accounts for geographic locations, number of transactions required over varying connectivity is necessary. In order to address these enterprise needs, the EEA is focusing on the following performance characteristics:
  • Define useful benchmarks based on various identified parameterizations of features
  • Sketch how clients could be instrumented to measure various kinds of performance
  • Relevant Parameters:
    • Node connectivity
    • Optimal network topologies (num and patterns of connections)
    • Reliability of connectivity (maintenance of connectivity among nodes)
    • Failure cases: when do nodes stop talking to each other
    • Safety
    • Liveness
    • Min. number of healthy honest nodes required for proper operation
    • Time to transaction finality
    • Total number of network nodes
    • Node topologies
    • Internode distances in terms of transmission time
    • Synchronous / Asynchronous messaging
    • Transactions per second throughput
    • Transaction / block transmission and processing latency
            

回复

使用道具 举报

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

QQ|小黑屋|手机版|Archiver|彩贝网络科技 ( 京ICP备13031603号

GMT+8, 2018-9-21 02:22 , Processed in 0.125001 second(s), 21 queries.

Powered by Discuz! X3.2 Copyright
© 2001-2013 Comsenz Inc.    All Rights Reserved.

快速回复 返回顶部 返回列表