Save
Saving
  • B
    brianliu

    Cryptography technology is the cornerstone of information technology. Blockchain uses a lot of technological achievements of modern information security and cryptography, mainly including: hash algorithm, symmetric encryption, asymmetric encryption, digital signature, digital certificate and so on. The hash algorithm solves the problem of information integrity verification, the symmetric algorithm improves the efficiency of encryption operations, the asymmetric algorithm solves the problem of symmetric key transfer, and the digital certificate is endorsed by the public key owner, which solves the problem of the public key holder's proof , PKI / CA system has formed a complete solution to solve information security, information confidentiality, integrity and non-repudiation.

    The current mainstream blockchain technology in China is called an open license chain. What is a license chain? It is the owner of all the nodes that make up the license chain. Their identities are authenticated, and they can only join the blockchain network after being authorized by the license.

    In this scenario, the network is open to authorized organizations or institutions, and there is a collaborative relationship between the participants on the chain, with an access mechanism. As a complete solution, the PKI / CA system can provide identity authentication certificates for each participant in the license chain to realize access control. It can be said that the certificate mechanism is the cornerstone of the permission chain network security. After the necessary description of the basic concepts of PKI / CA, this article elaborated the Ultrain certificate management system in detail.

    01 Public key infrastructure

    Public Key Infrastructure (PKI) is a collection of hardware, software, and policies, which is used to complete the generation, management, storage, distribution, and revocation of keys and certificates based on public key cryptosystem system.

    1.1 PKI system

    The PKI system includes a certificate authority CA (Certificate Of Authority, certification center), a registration authority RA and a corresponding PKI repository. CA is used to issue and manage certificates; RA can be used as a part of CA, or it can be independent. Its functions include personal identity verification, CRL management, key generation, and key pair backup. The PKI repository includes LDAP (Lightweight Directory Access Protocol, LDAP). Lightweight Directory Access Protocol) directory server and common database, used to store and manage user applications, certificates, keys, CRL (Certificate revocation lists) and logs, and provide certain query functions.

    1.2 Certificate application process

    • User application:

    The user generates his own public key and private key, submits the public key and his own identity information to the security server, and the security server transmits the user's application information to the RA server.

    • RA audit:

    The user proves his identity to the RA, and the RA checks after receiving the user's application. If the RA agrees with the user's request for a certificate, digitally sign the certificate application information; otherwise, the user's application is rejected.

    • CA issued certificate:

    The RA transmits the user application and the RA signature to the CA. The CA authenticates the RA digital signature. If the verification is passed, the CA agrees to the user request, issues a certificate, and then outputs the certificate. If the verification fails, the certificate application is rejected.

    • RA forwarding certificate:

    The RA obtains a new certificate from the CA, first outputs the certificate to the LDAP server to provide directory browsing, then notifies the user of the successful issuance of the certificate, informs the certificate of the serial number, and downloads the certificate to the specified website.

    • User certificate acquisition:

    The user uses the certificate serial number to specify the website to download his digital certificate.

    1.3 X.509 certificate format

    The mainstream certificate format is X.509 format. The X.509 standard stipulates what information a certificate can contain and explains how to record the information.

    X.509 structure includes Version Number, Serial Number, Signature Algorithm, Issuer, Validity, Subject, Subject Public Key Information (Subject Public) Key Info), subject public key algorithm (Public Key Algorithm), subject public key (Subject Public Key), certificate signature algorithm (Certificate Signature Algorithm) and certificate signature (Certificate Signature).

    1.4 Certificate verification principle

    1. Use the same hash function for the plain text in the certificate to get the digest value H1.

    2. Use the CA root certificate to verify the signature validity of the client certificate, that is, the signature in the certificate is de-signed with the public key of the CA root certificate, and the de-signed result is compared with H1 in step 1. If they are consistent, the certificate is trusted The root certificate is issued, and the contents of the certificate have not been tampered with.

    3. Check whether the client certificate is valid (the current time is within the validity period defined in the certificate structure).

    4. Check whether the client certificate is invalid (OCSP method or CRL method).

    5. Verify the purpose of the certificate in the client certificate structure.

    All the above information is verified, then the public key information of the client in the certificate can be used in subsequent operations.

    02 Ultrain Certificate Management System

    The authorized nodes of the permission chain form an alliance to share and access data. The PKI system is a complete and mature system for user auditing, identity management and privacy protection. Ultrain defines a set of top-down certificate management processes to achieve permission management and access control of license chain nodes.

    2.1 Ultrain certificate system

    Ultrain uses a CA-oriented access mechanism to implement authentication and dynamic management based on X.509 format certificates. According to the existing business scenario, the certificate system is shown in Figure 2, and includes the following types from top to bottom: root certificate, chain certificate, node certificate, and user certificate.

    Root certificate: The root certificate is a self-signed certificate, which is the root of all certificates, and the corresponding private key file is jointly managed by the alliance committee.

    Chain certificate: In a multi-chain architecture, a single chain management agency generates a chain private key and generates a request file chain.csr to send to the alliance committee. After the alliance committee passes the review, the chain certificate chain.crt is issued.

    Node certificate: The node certificate is issued by a chain certificate. The node generates and saves its own private key file node.key, and generates a request file node.csr and sends it to the chain management agency. After the chain management agency passes the verification, it issues a node certificate node.crt. The node certificate is the identity certificate of the node. The node with the node certificate can establish an SSL link with the node in the blockchain network to achieve encrypted communication between the nodes.

    User certificate: The user certificate is issued by the node that provides the chain access interface. The user generates and saves his own private key file sdk.key, and generates a request file sdk.csr and sends it to the node management organization that needs to be accessed. After the node management organization passes the verification, the user certificate sdk.crt is issued. The user certificate is the client's identity credential, and the client with the user certificate can access the link port normally.

    Ultrain provides a set of certificate application issuance management procedures to facilitate the application, verification and issuance of certificates at all levels.

    替代文字

    2.2 Certificate usage scenarios and verification

    The root certificate is jointly managed by the Ultrain Alliance Committee. At present, it uses a self-signed certificate. It can also be connected to a commercial certificate issuing agency and use a certificate issued by an authority. When the business needs to establish a new side chain, the side chain management agency submits the certificate request file, and the alliance committee uses the root certificate to issue the chain certificate after the alliance committee passes the review; the chain certificate is managed by the chain management committee, and the chain management committee receives the alliance member to become the operation The node certificate request file is issued by the committee after the committee passes the review; the alliance members use the node certificate to access the side chain node network before they can send and receive consensus and transaction information normally. If the node provides an on-chain data access interface, a user certificate needs to be issued to the client for use; the client uses the user certificate issued by a specific node to access the data interface provided by the node for data reading, transaction sending, etc. operating.

    Node certificate verification

    Node certificates are used when building chains between nodes. After the link based on certificate verification is established, the node can form a P2P network, so as to achieve the spread of consensus protocol information and transaction information. The following figure shows the process of using the node certificate.

    替代文字

    When a node is started, carrying its own node certificate can establish an SSL secure link with a node that also has the node certificate. When the certificate expires and is tampered with, it cannot be added to the P2P network, so the data on the chain cannot be shared and propagated.

    In Ultrain's certificate revocation (CRL) management system, the revocation of the certificate is completed by the certificate issuing authority. Nodes can periodically obtain the CRL list from the CA Management Center. Heartbeat messages between nodes need to carry their own node certificates. When the node certificate is not carried or the carried certificate is in the CRL list, the heartbeat message detection end will actively tear down the link with the detected end to achieve real-time access management control .

    User certificate verification

    When the client accesses the link port provided by the node, it can choose to verify the node certificate to verify the identity of the node. In this case, a certificate chain composed of a root certificate and a chain certificate needs to be used to verify the node certificate. In addition, the client needs to provide the user certificate to the node. The node's HTTPS service will verify the user certificate provided by the client (using the root certificate, chain certificate and node certificate to form the certificate chain for verification), and will also check the CRL revocation list , When the verification is passed and the user certificate is not in the CRL list, the SSL link is successfully established for normal communication, otherwise the link cannot be established, thereby ensuring the security of communication between the client and the node.

    posted in Activity read more
  • B
    brianliu

    密码学技术是信息技术的基石,区块链中大量使用了现代信息安全和密码学的技术成果,主要包括:哈希算法、对称加密、非对称加密、数字签名、数字证书等。哈希算法解决了信息完整性验证问题,对称算法提高了加密运算效率,非对称算法解决了对称密钥传递问题,数字证书则为公钥所有者背书,解决了公钥持有者的证明问题,PKI/CA 体系形成了解决信息安全、信息机密性、完整性和抗抵赖的完整解决方案。

    目前在中国主流发展的区块链技术被称为开放许可链,什么叫做许可链呢?就是所有组成许可链的节点所有者,其身份都是被认证过,被许可授权后,才能加入到该区块链网络的。

    在这种场景中,网络向授权的组织或机构开放,链上各参与方之间是一种协作关系,存在准入机制。PKI/CA 体系作为完整解决方案,可以为许可链各参与方提供身份认证证书,实现准入权限控制。可以说,证书机制是许可链网络安全的基石。本文对 PKI/CA 基本概念进行必要描述后,详细阐述 Ultrain 证书管理体系。

    01

    公钥基础设施

    公钥基础设施(Public Key Infrastructure,简称 PKI)是一个包含硬件、软件和策略等集合,用来实现基于公钥密码体制的密钥和证书的产生、管理、存储、分发和撤销等功能的完整系统。

    1.1 PKI 系统

    PKI 系统包括证书机构 CA(Certificate Of Authority,认证中心)、注册机构 RA 和相应的 PKI 存储库。CA 用于签发并管理证书;RA 可作为 CA 的一部分,也可以独立,其功能包括个人身份审核、CRL管理、密钥产生和密钥对备份等;PKI 存储库包括 LDAP(Lightweight Directory Access Protocol,轻量目录访问协议)目录服务器和普通数据库,用于对用户申请、证书、密钥、CRL(Certificate revocation lists)和日志等信息进行存储和管理,并提供一定的查询功能。

    alt text
    图1 PKI系统

    1.2 证书申请过程

    • 用户申请:

    用户生成自己的公钥和私钥,将公钥和自己的身份信息提交给安全服务器,安全服务器将用户的申请信息传送给 RA 服务器。

    • RA 审核:

    用户向 RA 证明自己的身份,RA 收到用户的申请后进行核对。如果 RA 同意用户申请证书的请求,则对证书申请信息做数字签名;否则拒绝用户的申请。

    • CA 发行证书:

    RA 将用户申请和 RA 签名传输给 CA,CA 对 RA 数字签名做认证,如果验证通过,则同意用户请求,颁发证书,然后将证书输出。如果验证不通过,则拒绝证书申请。

    • RA 转发证书:

    RA 从CA 得到新的证书,首先将证书输出到 LDAP 服务器以提供目录浏览,再通知用户证书发行成功,告知证书序列号,到指定的网址去下载证书。

    • 用户证书获取:

    用户使用证书序列号去指定网址下载自己的数字证书。

    1.3 X.509 证书格式

    主流的证书格式为 X.509 格式。X.509 标准规定了证书可以包含什么信息,并说明了记录信息的方法。

    X.509 结构中包括版本号(Version Number)、序列号(Serial Number)、签名算法(Signature Algorithm)、颁布者(Issuer)、有效期(Validity)、主体(Subject)、主体公钥信息(Subject Public Key Info)、主体公钥算法(Public Key Algorithm)、主体公钥(Subject Public Key)、证书签名算法(Certificate Signature Algorithm)和证书签名(Certificate Signature)。

    1.4 证书验证原理

    1. 对证书中的明文利用相同的散列函数得到摘要值 H1。

    2. 用 CA 根证书验证客户证书的签名合法性,即证书中的签名用 CA 根证书的公钥解签,解签的结果与步骤 1 中的 H1 对比,如果一致,说明证书是由信任的根证书签发,且证书的内容没有被篡改。

    3. 检查客户证书是否有效 (当前时间在证书结构中的所定义的有效期内)。

    4. 检查客户证书是否作废 (OCSP 方式或 CRL 方式)。

    5. 验证客户证书结构中的证书用途。

    上述所有信息都验证通过,那么证书中客户的公钥信息就能够在后续的操作中使用。

    02

    Ultrain 证书管理体系

    许可链经过授权的节点组成联盟从而共享和访问数据。PKI 体系是一套用户审核、身份管理和隐私保护的完整的、成熟的体系,Ultrain 定义了一套从上而下的证书管理流程,从而实现许可链节点的权限管理和访问控制。

    2.1 Ultrain 证书体系

    Ultrain 采用面向 CA 的准入机制,实现基于 X.509 格式证书的认证和动态管理。根据现有业务场景,证书体系如图 2 所示,自上而下包含以下类型:根证书、链证书、节点证书和用户证书。

    根证书:根证书是一个自签名的证书,为所有证书的根,对应的私钥 key 文件由联盟委员会共同管理。

    链证书:在多链架构中,单链管理机构生成链私钥,并生成请求文件 chain.csr 发送给联盟委员会,联盟委员会审核通过后签发链证书 chain.crt。

    节点证书:节点证书由链证书签发。节点生成并保存自己的私钥文件 node.key,并生成请求文件 node.csr 发送给链管理机构,链管理机构审核通过后签发节点证书 node.crt。节点证书是节点的身份凭证,拥有节点证书的节点能够与区块链网络中节点建立 SSL 链接,实现节点间的加密通信。

    用户证书:用户证书由提供链访问接口的节点签发。用户生成并保存自己的私钥文件 sdk.key,并生成请求文件 sdk.csr 发送给需要访问的节点管理机构,节点管理机构审核通过后签发用户证书 sdk.crt。用户证书是客户端的身份凭证,拥有用户证书的客户端才能正常访问链接口。

    Ultrain 提供了一套证书申请签发管理程序,方便各级证书的申请、验证及签发。
    alt text

    图2 Ultrain 证书体系

    2.2 证书使用场景及验证

    根证书由 Ultrain 联盟委员会共同管理,目前采用自签名证书,也可以与商业证书签发机构对接,使用权威机构签发的证书。当业务需要建立新的侧链时,该侧链管理机构提交证书请求文件,联盟委员会审核通过后使用根证书签发链证书;链证书由该链管理委员会进行管理,链管理委员会接收联盟成员成为运行节点的证书请求文件,委员会审核通过后签发节点证书;联盟成员使用节点证书以接入该侧链节点网络,才可以进行共识及交易信息的正常收发。如果该节点提供链上数据访问接口,则需签发用户证书提供给客户端使用;客户端使用特定节点签发的用户证书,才可以正常访问该节点提供的数据接口,进行数据读取、交易发送等操作。

    节点证书验证

    节点证书在节点间建链时使用。基于证书验证的链接建立之后,节点才能组成 P2P 网络,从而实现共识协议信息和交易信息的传播,下图为节点证书的使用流程。

    alt text

    图3 Ultrain 节点证书验证流程

    节点在启动时,携带自己的节点证书可以与同样拥有节点证书的节点建立 SSL 安全链接。当证书过期、被篡改时,不能加入到 P2P 网络中,从而不能共享和传播链上数据。

    在 Ultrain 的证书吊销(CRL)管理体系中,证书的吊销由该证书签发机构完成。节点可以向 CA 管理中心定期获取 CRL 列表。节点间的心跳报文中需携带自己的节点证书,当不携带节点证书或携带的证书在 CRL 列表时,心跳报文检测端会主动拆掉与被检测端的链接,实现实时的接入管理控制。

    用户证书验证

    客户端访问节点提供的链接口时,可以选择校验节点证书,以验证节点身份,此时需使用根证书、链证书组成的证书链对节点证书校验。另外,客户端需提供用户证书给节点,节点的 HTTPS 服务会校验客户端所提供的用户证书(使用根证书、链证书以及节点证书组成的证书链进行校验),同时会检查 CRL 吊销列表,校验通过且该用户证书不在 CRL 列表时,则成功建立 SSL 链接,进行正常通信,否则则不能建立链接,从而保证了客户端与节点间的通信安全。

    posted in 资讯 read more
  • B
    brianliu

    Ultrain Monthly Report(4.13–5.10)

    Following is the monthly report on the progress of the project from Apr. 13th -May.0th, which contains two items: project development progress and community dynamic update. It is for the community members to check. Thank you for your attention.

    Technology Update from Ultrain (4/13-5/10)

    Ultrain's Core Technology

    1. Complete the node code to support the development of the national secret algorithm switching function;

    2. Complete the development and deployment test of the light node world state Merkel verification scheme code;

    3. The performance of the OpenSSL national secret component SM2 is optimized, and the performance of verification is increased by 400%;

    4. The system contract is increased to provide a new solution for large-volume lock-up;

    5. Develop a new solution for the Windows version of the family mining machine;

    6. The system adds a transaction signature verification preprocessing and caching mechanism, and the overall TPS of the system is increased by 30%.

    Ultrain’s Ecosystem

    1. S.I.R. completes the development of the shop assistant activity and officially launches it;

    2. A new version of the S.I.R Merchant is released in the background, with online fund management, commodity management, store opening assistance and other functions;

    3. Complete the technical docking of the blockchain game stationed in the S.I.R system, and complete the preparation of the business online.

    Ultrain Developer Kit

    1. Complete U3 SDK to add national secret algorithm to support code development and testing;

    2. Complete the reconstruction of UltrainOne code and upgrade to use the latest version of RN.

    Ultrain’s Latest Community & Event Update

    Ultrain released "Adaptive Dynamic Networking" function on time

    On April 15, Ultrain successfully completed the release of the "Adaptive Dynamic Networking" function according to the planning of the 2020 technology roadmap. The code was released on Github as follows:

    https://github.com/ultrain-os/ultrain-core-production/tree/4.0.0

    This article describes in detail how Ultrain's "adaptive dynamic networking" function is designed technically, welcome to read the original text, technical breakthroughs | Adaptive dynamic networking method to improve the efficiency of blockchain consensus.

    Ultrain S.I.R. completed version iteration

    Ultrain independently developed a one-stop user growth technology service platform based on a small program store. The super-item system has completed iterations. It has a variety of powerful tool libraries to support the needs of merchant stores in multiple scenarios: SMS and subscription notifications, merchandise Fission posters, user relationship management ... In the future, there will also be functions such as social dynamics and interaction, live broadcast playback, etc.

    At present, Superphysical is engaged in store exploration and nugget activities, inviting merchants from all walks of life to open stores, and you will receive a reward for opening a store. Permanently receive 1% of the order transaction amount as a reward.

    alt text
    alt text

    Ultrain co-founder & CEO Guo Rui was interviewed by technology practitioners

    Recently, Guo Rui, co-founder and CEO of Ultrain, was interviewed by "Technologists" to discuss the opportunities that the blockchain industry can grasp in the new infrastructure environment, and said that the public chain is the key to building a new type of trust relationship.

    "Technology Walker" is an intelligent information service platform dedicated to recording and promoting AI industry applications, industrial development, technological innovation and AI Democracy. This time, the "Blockchain Revelation" column was launched to visit blockchain practitioners. In order to discover new opportunities and bring inspiration to the blockchain industry, Guo Rui is an important member of the interviewees.

    alt text

    Ultrain technical in-depth article released

    Recently, Ultrain technical experts wrote a special article to explain how Ultrain can reduce the cost of running full-node blockchain and expand the application scenarios of blockchain technology. On the basis of them, a new light node scheme is proposed, which can not only meet the functional requirements of verifying the specific value of the account at a certain time when the verification transaction has occurred, but also meet the performance and robustness requirements of the consensus. The performance is more than 10 times that of the Ethereum solution.

    The above is the progress report of Ultrain from Apr 13th to May 10th, looking forward to more exciting contents after that!

    posted in Activity read more
  • B
    brianliu

    替代文字

    以下为 2020 年 4 月 13 日- 5 月 10 日项目进展月报,包含#项目开发进展#、#社区动态更新#两项内容,供社区成员们查看,感谢大家对我们一直以来的热切关注!

    项目进展月报(4/13-5/10)

    项目开发进展

    • Ultrain 基础设施

    1. 完成节点代码支持国密算法切换功能开发;

    2. 完成轻节点世界状态默克尔校验方案代码开发并部署测试;

    3. OpenSSL国密组件SM2性能优化,验签性能提高400%;

    4. 开发Windows版本家庭矿机新解决方案;

    5. 系统增加交易签名验证预处理和缓存机制,系统整体TPS提高30%。

    • Ultrain 产品生态

    1. 超物系完成探店员活动相关开发并正式上线;

    2. 超物系商家后台发布新版本,上线资金管理,商品管理, 开店帮助等功能;

    3. 完成区块链游戏入驻超物系的技术对接,完成业务上线准备工作。

    • Ultrain 开发者套件

    1. 完成U3 SDK增加国密算法支持代码开发及测试工作;

    2. 完成UltrainOne代码重构,升级使用最新版本RN。

    社区动态更新

    • Ultrain 按时发布“自适应动态组网”功能

    4月15日,Ultrain按2020年技术路线图的规划,顺利完成了“自适应动态组网”功能的发布,代码发布在Github的如下TAG:https://github.com/ultrain-os/ultrain-core-production/tree/4.0.0

    本文详细介绍了Ultrain的“自适应动态组网”功能在技术上是如何设计的,欢迎戳原文阅读技术突破 | 提高区块链共识效率的自适应动态组网方法

    • Ultrain 超物系完成版本迭代

    Ultrain 独立开发的基于小程序店铺的一站式用户增长技术服务平台超物系完成版本迭代,具备多种强大的工具库用以支持商家店铺在多种场景下的需求:短信及订阅通知、商品裂变海报、用户关系管理... ...未来还将有社交动态及互动、直播观看回放等功能陆续上线。详情请戳我,一线城市打工族,工资6K,副业2W... ...

    目前超物系正火热进行探店掘金活动,邀请各行各业商家入驻开店,你就将得到开店奖励,与此同时,从今往后你邀请入驻的店铺每交易成功一笔,你都将永久获得订单成交金额的 1% 作为奖励。欢迎扫码了解更多

    替代文字

    替代文字

    Ultrain 联合创始人&CEO郭睿接受科技行者采访

    近期,Ultrain 联合创始人&CEO 郭睿接受“科技行者”采访,谈论新基建环境下区块链行业可以把握的机会,并表示公链才是构建新型信任关系的关键所在。

    “科技行者”是一个只谈智能的信息服务平台,致力于记录并推动 AI 行业应用、产业发展、技术创新和 AI Democracy,此次推出《区块链启示录》栏目,遍访区块链从业者以期从中发现新机遇、为区块链行业带来启示,而郭睿便是受访者其中重要一员。欢迎感兴趣的朋友们戳原文阅读新基建,新商业:用区块链构建新信任生态 。

    替代文字

    Ultrain 技术深度文章发布

    近日,Ultrain 技术专家特撰文讲解 Ultrain 如何降低运行区块链全节点成本、扩大区块链技术应用场景,表示比特币和以太坊用以解决此类问题的方案都存在一定的不足,而Ultrain在它们的基础上,提出了新的轻节点方案,既可以满足验证交易发生过和验证某个时刻账户的具体数值的功能性要求,同时也能满足共识在性能和健壮性方面的要求,其中在性能方面是以太坊方案的10倍以上。全文通用干货,欢迎戳原文阅读 如何降低运行区块链全节点成本?这里有全新轻节点方案

    以上便是 Ultrain 4 月 13 日至 5 月 10 日的项目进展,敬请期待此后的更多精彩内容!

    posted in 资讯 read more
  • B
    brianliu

    随着区块链网络的运行,节点数据量越来越大,运行区块链全节点的成本越来越高,现在一个区块链的全节点,区块数据存储量动辄就要几百G到上T,一方面直接导致运行全节点的区块链计算机的存储成本极大提高,如果我们想把区块链节点跑在一台普通PC上,光区块链数据就使用了普通PC一大半的硬盘存储空间,这显然是很难让人接收的;一方面也大大限制了区块链技术的应用场景,无论是手机还是IoT物联网设备,现在都不具备加载几T存储硬盘的能力。

    为了解决这个问题,不同的区块链平台都提出了各自的轻节点解决方案,其中比较典型的是比特币的SPV方案和以太坊的状态校验方案。但是这两种方案都存在一定的不足,比特币的SPV方案可验证交易确实发生过,但无法验证在某个时刻账户的具体数值;以太坊的状态校验方案即可以验证交易发生过,也可以验证某个时刻账户的具体数值,但由于该方案需要将数据写入块头,导致共识的性能下降以及健壮性降低。

    Ultrain在比特币的SPV方案和以太坊的状态校验方案基础上,提出了新的轻节点方案,既可以满足验证交易发生过和验证某个时刻账户的具体数值的功能性要求,同时也能满足共识在性能和健壮性方面的要求,其中在性能方面是以太坊方案的10倍以上。

    采取轻节点模式的节点不需要同步巨量的区块数据,利用世界状态默克尔校验方式,节点不需要重放历史区块即可校验状态的正确性,从而可以使能更多应用场景(比如在资源受限的嵌入式设备运行轻节点等)。本文将从世界状态校验问题引出,比特币SPV方案,以太坊世界状态校验方案以及Ultrain所采取的具体方案等方面对轻节点世界状态校验技术方案进行详细阐述。

    一、 节点同步数据量

    区块链节点网络可以理解为一个分布式的状态机,各个节点从相同的创世状态开始,根据每个区块内包含的交易,将创世状态逐块更新,形成不断更新的世界状态。随着时间的推移,每个节点本地存储的数据会不断增长,主要包括历史区块数据以及不断更新的世界状态数据。比特币创世至今135个月(2009/01~2020/03)所生产的区块累积数据量已经达263.6GB,且现在以每个月四个多GB的速度在增长。

    alt text

    图1 比特币区块大小(https://btc.com/stats/block-size)

    以太坊全节点以full模式进行同步时(节点会从网络同步所有的区块头,区块体并重放区块中的交易以生成世界状态数据),当前需同步的数据已经达到两三百GB,如对历史世界状态进行archive,则数据量已经超过4T。以太坊节点还支持fast模式进行同步,该模式与full模式的区别在于不重放区块中的交易去重构世界状态,而是从网络同步状态数据。此外,以太坊节点也支持light同步模式,此种模式下节点仅同步区块头数据,不同步区块体和状态数据,仅在需要相应的区块和状态时去从网络上获取。

    alt text

    图2 以太坊全节点同步数据量(https://etherscan.io/chartsync/chaindefault)

    alt text

    图3 以太坊全节点Archive模式数据量

    https://etherscan.io/chartsync/chainarchive)

    从以上比特币和以太坊的数据我们可以看出,部署运行一个全节点所需同步的数据量越来越大,从而导致节点机器硬件规格要求以及网络带宽门槛越来越越高。一个新节点需要花数天时间才能完成历史数据同步,然后才能开始参与共识过程进行出块。运行全节点成本比较高,在比特币白皮书中提到了轻节点可采用的SPV方案,可以在不同步全部区块数据的情况下,也能进行支付验证。这里的支付验证,只是验证该笔交易支付发生过,并不是验证交易的合法性(比如账户余额是否大于转账金额等)。

    二、 比特币SPV方案

    比特币白皮书中描述了SPV ( Simple Payment Verification ),即简单支付验证。SPV是一个在轻节点环境下,不用运行全节点、只需保存所有的区块头,就能验证支付有效性的技术方案。比特币中区块结构分为区块头和区块体两部分,区块头包含区块的必要属性,仅 80 字节大小;区块体包含当前区块下的所有交易,一般一个区块包含成百上千笔交易,每笔交易一般要 400 多字节。

    alt text

    图4 比特币区块结构

    如图4所示,比特币使用了默克尔树的数据结构来组织区块体内包含的交易:将区块内所有交易成对分组,并对交易进行哈希处理,然后对所得的哈希继续进行哈希处理,重复此过程,直到只剩下一个哈希,称为默克尔根(merkle root)。默克尔树底部的节点,就是交易数据的哈希值。每一个父节点,都是两个子节点哈希值组合后的哈希值。通过层层往上计算,最终算得根节点。这个默克尔根数值存储于比特币的区块头中。

    轻节点从区块链网络上获取了最长链上的所有区块头并在本地进行存储后,即可进行进行SPV支付验证:轻客户端首先计算待验证支付交易的哈希值;然后定位到包含该交易哈希所在的区块,并从区块中获取构建待验证支付交易默克尔树所需的哈希值序列;根据待校验交易的哈希值以及其所需哈希值序列,计算出默克尔根;将计算所得默克尔根数值与区块头中的默克尔根进行比对,如相等则证明交易是真实存在的。

    比特币区块头的大小始终是固定的80个字节,每小时出块约为6个,每年出块52560个,则每年新增的存储量约为4M 字节,SPV方案极大节省了轻节点的存储空间。从上述过程我们可以看出,比特币的这种SPV方案,仅确保校验的交易确实发生过,但不能用来校验交易所导致的世界状态的变化。以太坊在区块头中存储了交易的默克尔根数值,可以适用类似比特币的SPV方案;此外以太坊的区块头中还存储了世界状态的默克尔根数值,可以用来进行世界状态数值的校验。

    三、 以太坊世界状态校验方案

    以太坊的账户包含四个属性,nonce,balance,storageRoot和codeHash;以太坊用stateObject来管理账户状态,账户以Address为唯一标示;所有账户对象逐一插入Merkle-PatricaTrie(MPT)结构里,形成stateTrie。区块头数据结构中的Root字段存储了stateTrie的root数值,即世界状态的哈希值。

    alt text

    图5 以太坊区块头世界状态哈希字段

    我们假设在以太坊区块链上有两个账户A和账户B,初始账户余额均为10个以太币,在编号为1000的区块中发生过这样一笔交易:账户A向账户B转账一个以太币,将账户A的余额修改为9个以太币,账户B的余额修改为11个以太币(不考虑矿工费)。在与比特币SPV类似的以太坊的轻客户端中,我们可以利用在区块编号为1000块的块头中存储的交易的默克尔根数据,校验确实发生过账户A向账户B转账一个以太币这样一笔交易,但是仅利用交易的默克尔根数据,不能校验账户A的余额是不是9个以太币(或者账户B的余额是不是11个以太币),即不能校验世界状态的具体数值。

    在以太坊的区块头的世界状态默克尔根数值(字段Root)可以用来完成世界状态具体数值的校验。该字段为以太坊StateDB中的“state Trie”的根节点的RLP哈希值。区块中,每个账户以stateObject对象表示,账户以Address为唯一标示,其信息在相关交易(Transaction)的执行中被修改。所有账户对象可以逐个插入一个Merkle-PatricaTrie(MPT)结构里,形成“state Trie”。

    以太坊EIP-1186中增加了eth_getProof接口用于返回账号(account)及其状态(storage values)的默克尔校验所需的信息(merkle path),用于完成世界状态数值校验。eth_getProof有三个输入参数:

    1. DATA: 20字节 – 为账户的地址(外部账户/合约账户)

    2. ARRAY:32字节 – 为代校验状态数据的地址

    3. QUANTITY|TAG: – 为指定的区块编号或者字符串"latest" 或 "earliest"

    alt text

    图6 以太坊eth_getProof接口请求参数

    该接口返回数据如下:

    1. balance:账户余额

    2. codeHash:合约账户代码哈希数值,外部账户则返回固定数值

    3. nonce:账户nonce值,表示发了多少笔交易或创建了多少个合约

    4. storageHash:状态数值的默克尔根数值

    5. accountProof:账户校验所需的默克尔序列数组

    6. storageProof:状态数值校验所需的信息数组,包括以下字段:

    Ø key:状态数值对应地址

    Ø value:状态具体数值

    Ø proof:状态数值校验所需的默克尔序列数组

    alt text

    图7 以太坊eth_getProof接口返回数据

    轻节点通过eth_getProof接口获取上述返回信息后,首先根据返回的四个属性值[nonce, balance, codeHash,storageHash]构建账户对象,进行RLP编码后进行哈希操作,得到的数值与accountProof结合可以与在区块头中存储的世界状态默克尔树根数值进行校验;校验通过后,则相当于确认了storageHash字段的正确性,再结合storageProof中的默克尔序列可以完成对状态数值的校验。相关校验示例代码如下所示:

    alt text

    图8 以太坊状态校验示例代码

    四、 Ultrain世界状态校验方案

    以太坊采用MPT树(Merkle-PatricaTrie)管理所有账户对象,stateTrie存储了所有账户的信息,比如余额,发起交易次数,虚拟机指令数组等信息,随着每次交易的执行,stateTrie 其实一直在变化,区块内所有交易完成后,所有账户信息的即时状态的默克尔根数值会记录到区块头中。

    Ultrain采用chainbase存储所有世界状态信息,区块内交易执行会更新chainbase内相关对象的状态数值,因此chainbase内存储了世界状态的实时信息。客户端通过链上接口(get_table_records)查询chainbase内信息时,实际上是信任接口提供方,从而信任其提供的数据的正确性;且该接口只能提供实时状态信息,不能查询指定块高状态数值。Ultrain世界状态校验方案可指定块高查询状态信息,并提供该状态信息校验所需的默克尔路径信息,从而去除对接口提供方的信任依赖。

    Ultrain世界状态校验方案中,每个矿工节点在区块交易执行结束时,将本区块内所有交易对世界状态所做的所有修改(即对chainbase内存储数据的修改)进行序列化处理,并按一定顺序组织为默克尔树的叶子节点,再逐层计算得出该区块世界状态变化的默克尔根数值,计算所得的默克尔根数值会保存到内存中。当区块高度到一定间隔(比如每100块)时,将间隔内所有区块的世界状态变化的默克尔根数值再做一次默克尔根数值计算,并将该结果(称之为世界状态变化累计默克尔根数值)以及间隔内每个区块的块高与对应的默克尔根数值写入文件系统。为防止对主线程性能造成影响,这部分逻辑采用单独的线程完成。所有矿工节点会将世界状态变化累计默克尔根数值通过链上交易写入系统合约,只有超过2/3矿工汇报相同默克尔根数值时,该数值才会生效。

    为提供世界状态校验查询功能,需设置提供世界状态查询服务的节点。选取非矿工节点(即只接收交易和区块,不参与共识过程的节点)在每个区块内交易执行完全结束后,将该区块内所有对世界状态的修改序列化后存储到文件系统,并响应校验查询节点的数据请求,将状态变化数据发送给查询节点进行存储。查询节点采用rocksdb将每个区块对世界状态的修改进行存储,包括块高(block_num),修改序号(sequence),修改内容(修改后的具体状态内容);查询节点在存储每块数据的同时,与矿工节点类似计算每个区块对应的世界状态变化的默克尔根数值,并将该数值存储到rocksdb中。此外,查询节点为轻节点提供查询接口,响应其查询请求。

    alt text

    图9 Ultrain世界状态校验查询节点与非矿工节点交互

    轻节点对特定世界状态进行查询校验的时候需经过如下三个步骤:

    1)首先采用 get_table_rows接口查询具体世界状态数值,该接口需输入要查询的世界状态所在的数据表信息(code,scope,table)以及限定的区块块高信息:

    alt text

    返回数据包括该条状态的具体信息(如示例中data字段的账户余额)以及该信息对应的二进制字节(示例中的raw字段,该字段也可以由轻节点根据合约的ABI文件自己生成);此外,该接口会返回这条世界状态修改对应的块高(block_num)及序号信息(sequence)。

    alt text

    2)根据get_table_rows接口返回的块高及序号信息,获取对应的校验该状态所需的默克尔树序列信息,轻节点调用如下接口:

    alt text

    该接口返回的paths字段即为默克尔树序列信息:

    alt text

    3)根据get_table_rows返回的raw数据以及get_table_row_proof返回的paths数据,轻节点可以调用如下接口,计算默克尔树根数值(轻节点也可以自己实现根据raw和paths数据计算默克尔根的逻辑):

    alt text

    该接口返回计算所得的默克尔根数值,该值可以与矿工节点通过交易写入系统合约的对应的数值进行比对,相同则表示校验通过(该示例中发生世界状态改变的区块高度为34186,如矿工节点所选取的区块间隔为100的话,则应该从系统合约读取块高34200对应的默克尔根数值进行比对)。

    alt text

    综上所述,轻节点与查询服务节点交互流程如下图所示:

    alt text

    文中所述比特币的SPV方案,以太坊的状态校验方案以及Ultrain的状态校验方案,我们可以看到轻节点不需要再同步大量的数据,即可验证交易确实发生过,以及验证在某个时刻世界状态具体数值,由此轻节点所需的存储及计算资源大幅降低,可以在资源受限的嵌入式设备上运行轻节点,比如物联网设备,实现物联网与区块链技术的结合,使能更多商业场景。

    posted in 资讯 read more
  • B
    brianliu

    On April 15th, Ultrain successfully completed the release of the “Adaptive Dynamic Networking” function according to the planning of the 2020 technology road map.

    https://github.com/ultrain-os/ultrain-core-production/tree/4.0.0

    One of our technical goals this year is to hope that through blockchain technology, we will focus on empowering fully competitive industries and helping them to establish low-cost mutual trust franchise business models.

    We envisage such a business scenario, a provincial catering alliance with 1,500 franchised stores with more than 20 catering brands in the province. They hope to achieve the exchange of catering consumption points within the alliance so that consumers can redeem within the brand points can be exchanged for use in more than twenty brands. In the traditional business environment, this kind of assumption is difficult to establish, because the points platform is generally built and controlled by the leader. Under traditional technical means, even if the leader shows how open and transparent, it is difficult for the affiliated companies to trust The platform does not violate the rules and secretly issues additional points, because this is an act that can directly bring benefits to the leader, and it is difficult for the leader to prove himself innocent here.

    We can solve this problem with Ultrain blockchain technology. We can deploy 1500 nodes in 1500 franchise stores. Each franchise store provides its own computer and installs Ultrain blockchain software on the computer. The computers are organized into an Ultrain blockchain network, and the behavior data such as the issuance, circulation, exchange, and consumption of points will be directly recorded in the Ultrain blockchain network, and the data will be synchronized to these 1500 computers at the same time. Modify or delete the relevant data of these points, in this way, all franchise stores can trust this set of points system and join the operation.

    If blockchain technology can support this business scenario, we have multiple technical points to break through. For example, the computer is controlled by each store, some computers may run for a long time, some computers may only be turned on when the store is at work, and will be turned off after work, and the work hours of each store are different, so the computer is turned on and off The time will also be different; at the same time, because it is running on the public network, the network status will be good and bad, and there may be situations where some computers suddenly deteriorate the network status and cannot connect to the network. Therefore, we are faced with the situation of a dynamic computer network. There are computers joining and exiting at any time in this network, and the number of online computers is not fixed.

    In the traditional blockchain BFT consensus protocol, if more than 1/3 of the computers in the network are offline and not in the network, the entire blockchain network will be paralyzed. However, in the above business scenario, this situation is likely to occur. Ultrain’s “adaptive dynamic networking” technology effectively solves this problem. In the process of the gradual decrease of the number of nodes in the Ultrain blockchain network due to various reasons, the Ultrain network can dynamically adapt to this process. Even in the case where more than 1/3 of the computers in the network are offline, the Ultrain network can be kept Long-term stable operation. After the disconnected node comes back online, the Ultrain network will also automatically connect these “resurrected” nodes to the network and let it continue to provide services.

    Now let’s introduce how the “Adaptive Dynamic Networking” function of Ultrain is designed technically.

    Blockchain is a special distributed database. The system generates accounting nodes in committee nodes according to a certain consensus algorithm, records and modifies information on the chain, and synchronizes to all committees. The consensus algorithm based on BFT has the following two problems:

    1. With a certain probability, the members of the committee that are not online are selected as the accounting nodes, and effective blocks cannot be produced. This will lead to empty blocks in the current accounting process.

    2. When a large number of committee members gradually go offline, the consensus algorithm of BFT cannot be completed, and the system will be stuck in the current round and cannot continue. The entire blockchain network is paralyzed.

    Ultrain proposes a solution based on discrete heartbeat signals for two issues of consensus. Each monitored node is set with a separate monitoring time to prevent startling effects.

    Adaptive dynamic networking includes the following steps:

    1. The number of all effective committee members in the blockchain is m, and the BFT consensus algorithm will generate a data block on the blockchain within each block generation period t;

    2. To deploy a heartbeat monitoring smart contract on the blockchain, all valid committee members in the blockchain must send the sign-in transaction in the heartbeat monitoring smart contract within the specified time interval T, complete the sign-in on the chain, and then extract nodes for inspection Remove valid committee members who have not checked in.

    Setting different checkpoints for each group (one) node can effectively prevent the instantaneous system paralysis caused by the shock group effect.

    Extract nodes for inspection, and remove valid committee members who have not checked in, including:

    A) Divide the interval time T into n time nodes (slots, hereinafter referred to as checkpoints), and the interval of each checkpoint is T / n;

    B) Based on the association of the nodes, divide the nodes into several sets;

    C) A node is randomly selected from each valid set for inspection to form a sampling set for this checkpoint;

    D) No sign-in will be removed from the effective committee;

    E) For the set with abnormal nodes, the sampling weight α will be increased at the next checkpoint;

    In step A), n is determined by the correlation degree δ, and the range of the correlation degree δ is 0 ~ 1.

    In step B), based on the association of the nodes, the nodes are divided into several sets, including:

    a) Divide all nodes into 24 sets Ci, where 0≤i≤23;

    For blockchain nodes, whether they can provide computing power normally is closely related to time. Therefore, we use the time zone division method to first divide all nodes into 24 sets, set Ci (0≤i≤23);

    b) The set with no more than Min nodes is unified to the left, where Min is set to 3% of the total number of nodes;

    For example, if the number of Ci nodes in the set is less than Min, then they are grouped into the Ci-1 set;

    c) Delete the empty collection generated after the collection to get a valid collection;

    d) A two-dimensional feature attribute is used to describe the node (X, Y), where X is the number of the time zone to which it belongs, and Y is the number of historical blocks of the node;

    e) Select

    alt text

    centroids for each effective set,

    alt text

    where N (Ci) is the number of nodes in the set Ci;

    f) Nodes (X, Y) and

    alt text

    centroids use K-Means algorithm to find K node clusters, among which,

    alt text

    complete the node division into several sets;

    Using the K-Means algorithm, (X, Y) can be set according to specific network characteristics. For example, for a time-sensitive network, the X weight can be set to 99%, and the Y weight can be set to 1%.

    In step E), the set of nodes where the problem is checked at this checkpoint, according to their relevance, the probability that there are still abnormal nodes becomes higher, so in the next sampling, the weight α is increased.

    In this scheme of Ultrain, the h abnormal committee nodes are screened in time by the heartbeat method (contract) and the committee is removed, then the number of effective committees becomes m ’= m-h.

    Each round of consensus selects the accounting node only from the effective committee, which can effectively avoid the offline committee.

    At the same time, the scheme will temporarily remove the abnormal node from the committee. Even if this part of the node participates in the consensus, it will be treated as an invalid node, which will prevent the occurrence of evil.

    When the committee comes back online and sends the heartbeat method, the system adds it back to the list of alternative committees. Can continue to participate in consensus.

    This solution of Ultrain divides the online status of the system committee into 5 categories:

    1. Low risk, less than 5% of offline nodes;

    2. Medium and low risk state, 5% -15% of offline nodes;

    3. Medium risk state, offline nodes 15% -30%;

    4. High-risk state, offline nodes 30% -33%;

    5. When the downtime state exceeds 1/3, the node is not online.

    Compared with the existing technology, this solution of Ultrain has the following advantages:

    The common heartbeat monitoring in the prior art generally has a uniform monitoring period T. When the time is up, it detects which nodes have not sent heartbeat messages in time. This will bring a potential risk, that is, the nodes that exceed the threshold at a certain period are abnormal at the same time. This phenomenon will bypass the heartbeat monitoring system and bring a catastrophic blow to the system. The probability of this situation is proportional to the monitoring period T. In this scheme of Ultrain, setting different checkpoints for each group (one) node can effectively prevent the instant system paralysis caused by the shock group effect.

    Next, we quantitatively prove that this scheme is significantly better than existing heartbeat monitoring.

    Specifically, assuming that the total node set M = 96, the nodes are independent of each other, and the probability of abnormal occurrence of each node p = 10%, and the probability of simultaneous abnormality of nodes exceeding f = 1/3 P = p ^ (m * f) Is very low.

    But complete independence is theoretical, and in reality, many nodes have relevance. On the network, some habits of the operator. For example, some nodes will be turned off at night. This greatly increases the instability of the blockchain.

    We further simplify the model, forming M = 96 according to the step k-means algorithm to form a K group, the nodes in the group are related, the correlation coefficient δ = 1 (that is, the degree of association δ = 1), and the groups are independent of each other.

    We assume that at a certain time, multiple nodes of the system are down, the system enters a high-risk state, and will be down at any time, and the probability of empty blocks is close to 1/3, and the system is in a low availability state. Risk state time to prove the advantages of this program.

    According to our definition of the node group model above, suppose that the nodes of the two groups are down, the set B of the downtime, any bi∈B is not online, | B | = 32, B∈M we need to detect more than y = 5 nodes to get the system out of high-risk areas.

    We divide the period T into M / K checkpoints. At each checkpoint, a node is randomly selected from the K-node cluster to check the punching of the heartbeat method.

    At the first checkpoint, a node is randomly selected from the K node clusters obtained by the k-means algorithm in step 2 to form a set H, where H ∈ m if | H∩B | ≥5, it is set H and B The number of intersections exceeds 5, which means that at the first checkpoint, more than 5 outage nodes are detected, making the system out of the high-risk area. The probability of this event:

    alt text

    Among them, P (| H∩B | ≥5) represents the probability that the number of intersections of sets H and B exceeds 5.

    alt text

    represents the combined type of k nodes extracted from the total set M,

    alt text

    means that from the set B, that is, the set of faulty nodes, the type of the i elements is taken from the elements (0≤i≤4),

    alt text

    k-i node combination types are extracted from the M-B set, and the probability that more than 5 outage nodes can be detected before the nth (1≤n≤6) checkpoint is determined by the recursive method, as shown in Table 1:

    alt text

    From the data analysis, it can be seen that the system recovers from the high-risk state with a probability of 67.9% at T / 6, while the probability of the system recovering from the high-risk state at T / 3 exceeds 99.9%, which is much better than the fixed time monitoring algorithm.

    Using time-shared random monitoring, the expected time to recover from a high-risk state changes from T to 0.22T.

    Obviously, if we can divide T into more time periods, the time can be expected to move more, as shown in Figure 1.

    alt text
    It can be seen that the expected recovery time does decrease with the increase of detection density, and different parameters can be set according to different system requirements.

    After using this scheme, the blockchain consensus algorithm will be more robust.

    When some nodes begin to go offline gradually, they will stop sending heartbeat transactions, and the blockchain system will sense this change in time and strip the abnormal committee members from the committee.

    BFT’s consensus algorithm is fault-tolerant for a small number of committee members offline. But when the offline node exceeds 1/3 of the committee, the system cannot reach the consensus of BFT, and then becomes paralyzed. This solution will promptly remove the invalid committee members from the committee to repair the BFT system, so that the entire consensus system can continue to operate effectively.

    posted in Activity read more
  • B
    brianliu

    4月15日,Ultrain按2020年技术路线图的规划,顺利完成了“自适应动态组网”功能的发布,代码发布在Github的如下TAG:

    https://github.com/ultrain-os/ultrain-core-production/tree/4.0.0

    我们今年的技术目标之一,是希望通过区块链技术,重点赋能充分竞争的行业,帮助其低成本建立互信的加盟制商业模式。

    我们设想这样一个商业场景,一个省级餐饮联盟,在全省有二十几个餐饮品牌的1500家加盟店,他们希望在联盟内实现餐饮消费积分的互相兑换,让消费者在品牌内可以兑换积分,在二十几个品牌内也可以互相兑换使用。在传统的商业环境下,这种设想是很难建立的,因为积分平台一般是由盟主来建设和控制的,在传统的技术手段下,即使盟主如何表明自己公开透明,加盟企业也很难信任平台没有违背规则,自己偷偷增发积分,因为这是对盟主可以直接带来收益的行为,盟主在这里很难自证清白。

    我们可以通过Ultrain区块链技术来解决这个问题,我们可以在1500家加盟店内部署1500个节点,每个加盟店自己提供一台电脑,在电脑上安装Ultrain区块链软件,就可以将这1500台电脑组织成一个Ultrain区块链网络,积分的发行、流转、兑换、消耗等行为数据都会直接记录到Ultrain区块链网络中,该数据会同时同步到这1500台电脑中,没有任何方法可以修改或删除这些积分的相关数据,通过这种方式,所有加盟店都可以信任这套积分体系并加入运营。

    如果区块链技术可以支持这个商业场景,我们有多个技术点需要突破。比如电脑是由各个店家控制的,有些电脑可能会长期运行,有些电脑可能就是在店家上班时才会开启,下班后就会关闭,同时各个店家的上下班时间也不一样,所以电脑开启和关闭的时间也会不同;同时由于是在公网中运行,网络的状况也会时好时坏,会存在部分电脑突然网络状况恶化,无法链接到网络的情况。所以,我们面对的是一个动态电脑网络的情况,这个网络中随时都有电脑加入和退出,同时在线的电脑数量是不固定的。

    在传统区块链的BFT共识协议中,如果网络中超过1/3的电脑都掉线和不在网络中,整个区块链网络就会瘫痪了。但在上述的商业场景中,这种情况很有可能出现,Ultrain的“自适应动态组网”技术有效的解决了这个问题。在Ultrain区块链网络由于各种原因其节点数量逐步减少的过程中,Ultrain网络可以动态适应这个过程,甚至在网络中超过1/3的电脑都掉线的情况下,也可以保持Ultrain网络一直长期稳定地运行,在断线的节点恢复上线以后,Ultrain网络也会自动将这些“复活”的节点接入到网络中,让其继续提供服务。

    下面我们来具体介绍下Ultrain的“自适应动态组网”功能在技术上是如何设计的。

    区块链是一种特殊的分布式数据库,由系统在委员会节点中按照一定共识算法产生记账节点,记录和修改链上信息,并同步到所有委员会。基于BFT的共识算法,都存在以下两个问题:

    l一定概率下选中了不在线的委员会成员作为记账节点,无法生产有效块。进而导致本轮记账过程出空块。

    l当大量委员会成员逐渐掉线后,会导致无法完成BFT的共识算法,系统就会停滞在当前轮,无法继续进行。整个区块链网络就瘫痪了。

    Ultrain针对共识的两个问题,提出一种基于离散心跳信号的解决方案。采用每一个被监控节点设置单独的监测时间,防止惊群效应。

    自适应动态组网包括以下步骤:

    1)区块链中所有有效委员会成员的数量为m,采用BFT的共识算法在区块链上在每个出块周期t内会产生一个数据块;

    2)在区块链部署心跳监测智能合约,区块链中所有有效委员会成员必须在规定的时间间隔T内,发送该心跳监测智能合约中的签到交易,完成链上签到,之后抽取节点进行检查将没签到的有效委员会成员移除。

    为每一组(一个)节点设置不同的检查点,可以有效的防范惊群效应带来的瞬间系统瘫痪。

    抽取节点进行检查,将没签到的有效委员会成员移除,具体包括:

    A)将间隔时间T分成n个时间节点(slot,以下简称检查点),每个检查点的间隔为T/n;

    B)基于节点的关联性,将节点划分成为若干集合;

    C)随机从每个有效集合中抽取一个节点进行检查,形成本检查点的抽样集合;

    D)没有签到的,将被从有效委员会中移除;

    E)对于有异常节点的集合,将在接下来的检查点,增加抽样权重α;

    步骤A)中,所述的n通过关联度δ确定,关联度δ的取值范围为0~1。

    步骤B)中,基于节点的关联性,将节点划分成为若干集合,具体包括:

    a)将所有节点划分成为24个集合Ci,其中0≤i≤23;

    对于区块链节点,是否能正常提供算力,跟时间有密切关系,因此,我们采用时区划分的方式,首先将所有节点划分成为24个集合,集合Ci其中(0≤i≤23);

    b)对于节点数不超过Min的集合统一向左归集,其中,Min设为总节点数的3%;

    比如,集合Ci节点数少于Min,那么就将它们归集到Ci-1集合;

    c)删除归集后产生的空集合,得到有效集合;

    d)用一个二维特征属性来描述节点(X,Y),其中,X是所属时区的编号,Y是该节点的历史出块数;

    e)每个有效集合选出

    alt text

    个质心,

    alt text

    ,其中,N(Ci)是集合Ci的节点数;

    f)节点(X,Y)和

    alt text

    个质心利用K-Means算法,求出K个节点簇,其中,

    alt text

    ,完成节点划分成为若干集合;

    利用K-Means算法,(X,Y)可根据具体网络特点设置,比如,对于时间敏感的网络可将X权重设置为99%,Y权重可设置为1%。

    步骤E)中,这个检查点上被检查出问题的节点集合,根据其关联性,仍然存在异常节点的概率变高了,所以在接下来的抽样中,就增加权重α。

    在Ultrain的这种方案中,这h个异常的委员会节点被心跳方法(合约)及时甄别出来,并移除委员会,那么有效委员会数量就变成m’= m-h。

    每一轮共识选取记账节点时只会从有效委员会中选取,可以有效避开不在线的委员会。

    同时该方案,临时将异常节点移除委员会,即使这部分节点参与了共识,也会被当做无效节点处理,杜绝了作恶的发生。

    当委员会重新上线,发送该心跳方法后,系统将它加回备选委员会列表。可以继续参与共识。

    Ultrain的这种方案将系统的委员会在线状态分为5种:

    1、低风险状态,不在线节点少于5%;

    2、中低风险状态,不在线节点5%-15%;

    3、中风险状态,不在线节点15%-30%;

    4、高风险状态,不在线节点 30%-33%;

    5、宕机状态超过1/3节点不在线。

    与现有技术相比,Ultrain的这种方案具有如下优点:

    现有技术中的普通的心跳监控,一般有一个统一的监控周期T,时间到了,就检测哪些节点未及时发送心跳消息。这会带来一个潜在的风险,就是在某一个周期超过阈值的节点同时异常,这种现象会绕过心跳监控系统,给系统带来灾难性的打击。而这种情况的概率,跟监控周期T成正比。而Ultrain的这种方案中,为每一组(一个)节点设置不同的检查点,可以有效的防范惊群效应带来的瞬间系统瘫痪。

    接下来,我们定量证明该方案的显著优于现有的心跳监控。

    具体地,假设总节点集合M = 96,节点间相互独立,每个节点发生异常的概率p= 10%,超过f=1/3 节点同时发生异常的概率P = p^(m*f)其实是很低的。

    但是完全相互独立是理论上的,现实中,很多节点都有相关性。网络方面,操作者的一些习惯。比如有些节点会在夜间被关掉。这就大大增加了区块链的不稳定性。

    我们进一步简化模型,将M=96根据步骤k-means算法,组成K群组,组内节点具有关联性,相关系数 δ = 1(即关联度δ=1),群组间相互独立。

    我们假设在某个时间,系统多个节点宕机,系统进入高风险状态,随时都会宕机,而且出空块的概率接近1/3,系统处于低可用状态,这个时候,通过比较系统脱离高风险状态的时间来证明本方案的优势。

    根据我们上面对节点群组模型的定义,假设两个群组的节点宕机,宕机的集合B,任意bi∈B不在线,|B|= 32,B∈M我们需要检测出超过y =5个节点才能使系统脱离高风险区域。

    我们将周期T分成M/K个检查点,每个检查点,随机抽取K节点簇中抽取一个节点来检查心跳方法的打卡情况。

    在第一个检查点随机从步骤2中用k-means算法求得的K个节点簇中抽取一个节点组成集合H,其中H∈m则若|H∩B|≥5,就是集合H和B的交集数量超过5个,意味着,在第一个检查点,就检测到了超过5个宕机节点,使得系统脱离高风险区域。这个事件发生的概率:

    alt text

    其中,P(|H∩B|≥5)表示集合H和B的交集数量超过5个的概率,

    alt text

    表示从总集合M抽取k个节点的组合种类,

    alt text

    表示从B集合也就是出故障节点集合,元素中取i个元素的种类其中(0≤i≤4),

    alt text

    从M-B的集合中抽取k-i个节点组合种类,通过递归法逐项求得在第n(1≤n≤6)个检查点以前能检测到超过5个宕机节点的概率如表1所示:

    alt text

    表1 分时随机监测与固定时间监测对比

    从数据分析,可以看出在T/6 的时候系统由67.9%的概率从高危状态恢复,而在T/3时候系统从高危状态恢复的概率超过99.9%大大优于固定时间监测的算法。

    采用分时随机监测,从高危状态恢复的期望时间从T变成0.22T。

    显然,如果我们可以将T分成更多的时间段,期望时间可以更加的迁移,如图1所示。

    alt text

    可以看出期望恢复时间确实是随检测密度增加而减少,根据不同系统需求,可以设置不同的参数。

    使用该方案后,区块链共识算法就会更加健壮。

    当有部分节点开始逐渐离线时,它们就会停止发送心跳交易,区块链系统会及时感知到这一变化,将异常委员会成员从委员会中剥离。

    BFT的共识算法对少量委员会成员离线是有容错机制的。但是当离线节点超过委员会的1/3后,系统就无法达成BFT的共识,进而瘫痪。本方案会及时将失效的委员会成员移出委员会来修复BFT系统,使得整个共识系统可以持续有效运行。

    posted in 资讯 read more
  • B
    brianliu

    alt text

    Ultrain Monthly Report(03/16–04/12)

    Following is the monthly report on the progress of the project from Mar. 16th -Apr. 12th, which contains two items: project development progress and community dynamic update. It is for the community members to check. Thank you for your attention.

    Technology Update from Ultrain (3/16–4/12)
    Ultrain’s Core Technology

    1. According to the Central Bank’s “Financial Distributed Ledger Technical Security Specification” compliance check and improve the node code;

    2. The node code adds national secret algorithm support to the transaction account;

    3. Establish an on-chain data table to support miners’ daily reward data on-chain storage;

    4. Optimize the historical data query code and improve the browser query response speed;

    5. Calculate the Merkel tree hash of the world state change data to provide world state data verification.

    Ultrain’s Ecosystem

    1. A new version of the user relationship diagram, store settings and other functions are launched on the backstage of the merchant, which completes the development of funds management, product management, store opening help and other pages, and is scheduled to go online at the end of April;

    2. The new version of the Hyper-physical APP is launched, optimizing the rich text display on the product detail page, optimizing the homepage effect and other functions;

    3. Optimize the merchant entry process, complete function development such as shop reward activities and shop package purchase, and plan to go online after passing the test in early May.

    Ultrain Developer Kit

    1. U3 SDK adds national secret algorithm support;

    2. Optimize the Ultrain One wallet wealth page to support reading on the miner reward data chain;

    3. Optimize Ultrain One wallet transfer code to improve transfer response speed.

    Ultrain’s Latest Community & Event Update

    Ultrain overseas ambassadors synchronized the development of the blockchain industry around the world

    In March, due to multiple factors, the global financial market was in crisis. But at the same time, in this special period, emerging technologies such as blockchain have also accelerated. Ultrain’s overseas ambassadors conducted a survey to provide you with an in-depth understanding of the development of the blockchain industry around the world.

    Ultrain wished community members a happy April Fools’ Day!

    alt text

    Ultrain launched the technology roadmap of 2020

    The Ultrain mainnet has been running steadily for a year since it was launched on 2019.4.15. On the basis of technical stability and shaping, Ultrain ’s main task in 2020 is to achieve the commercial implementation of blockchain technology, and it has clarified the business model that hopes to be empowered by Ultrain technology in 2020: in a fully competitive industry To establish a mutual trust franchise business model through low cost.

    In order to achieve this goal, Ultrian’s technology needs to be further upgraded from the following aspects in 2020: 1. Compliance with business compliance requirements; 2. Consensus innovation; 3. Blockchain privacy protection. We have further divided the technical route.

    alt text

    The above is the progress report of Ultrain from Mar 16th to Apr 12th, looking forward to more exciting contents after that!

    posted in News read more
  • B
    brianliu

    为丰富项目进展报告内容,提高报告整体质量,Ultrain 决定从今起将原本的双周报改为月报形式。以下为 2020 年 3 月 16 日- 4 月 12 日项目进展月报,包含#项目开发进展#、#社区动态更新#两项内容,供社区成员们查看,感谢大家对我们一直以来的热切关注!

    项目进展月报(3/16-4/12)

    项目开发进展

    • Ultrain 基础设施

    1. 根据央行《金融分布式账本技术安全规范》合规排查并完善节点代码;

    2. 节点代码为交易账号增加国密算法支持;

    3. 建立链上数据表,支持矿工每日奖励数据上链存储;

    4. 优化历史数据查询代码,提高浏览器查询响应速度;

    5. 对世界状态变化数据计算默克尔树哈希,以提供世界状态数据校验。

    • Ultrain 产品生态

    1. 商家后台上线新版用户关系图,店铺设置等功能,完成资金管理,商品管理, 开店帮助等页面开发,计划4月底上线;

    2. 超物系APP新版本上线,优化商品详情页富文本展示,主页效果优化等功能;

    3. 优化商家入驻流程,完成探店奖励活动和店铺套餐购买等功能开发,计划5月初测试通过后上线。

    • Ultrain 开发者套件

    1)U3 SDK 增加国密算法支持;

    2)优化UltrainOne 钱包财富页面,支持矿工奖励数据链上读取;

    3)优化UltrainOne 钱包转账代码,提高转账响应速度。

    社区动态更新

    • Ultrain 海外大使同步各地区块链行业发展实况

    3 月,受多重因素影响,全球金融市场危机四伏。但与此同时,在这个特殊时期,区块链等新兴科技也得到了加速发展。Ultrain 特连线海外大使进行了调研,供大家深入了解世界各地区块链行业的发展实况。详情请戳恐慌情绪下,全球区块链行业的「危」与「机」

    • Ultrain 祝社区成员 4 月 1 日愚人节快乐!

    替代文字

    Ultrain 重磅发布 2020 年技术路线图

    Ultrain 主网于 2019.4.15 上线以来,已稳定运行了一年的时间。在技术稳定和成型的基础上,Ultrain 在 2020 年的主要任务是实现区块链技术在商业上的落地,已明确了 2020 年希望通过 Ultrain 技术重点赋能的商业模式:在充分竞争的行业中,通过低成本建立互信的加盟制商业模式。

    为实现此目标,2020 年 Ultrian 的技术还需要从以下几个方面进一步升级:1. 符合商业合规要求;2. 共识创新;3. 区块链隐私保护。我们对该技术路线做了进一步的划分,详情请戳重磅发布 | Ultrain 2020 年技术路线图

    替代文字

    以上便是 Ultrain 3 月 16 日至 4 月 12 日的项目进展,敬请期待此后的更多精彩内容!

    posted in 资讯 read more
  • B
    brianliu

    The Ultrain main net has been running steadily for a year since it was launched on 2019.4.15. At present, the Ultrain network is composed of nearly 700 nodes, which are distributed in many countries and regions such as China, the East and West Coast of the United States, Australia, South Africa and Germany. The network deployment methods include public cloud networks (Alibaba Cloud, Amazon Cloud, Microsoft Cloud, Kingsoft Cloud), enterprise intranet, enterprise private network, open Internet and home broadband network.

    On the basis of technical stability and shaping, Ultrain’s main task in 2020 is to realize the commercial implementation of blockchain technology. In the second half of 2019, we spent a lot of energy exploring and designing business models with our many business partners, and we have a full understanding of the advantages and disadvantages of blockchain technology in business competition:”Blockchain Business and Technology Status and Development Trend Outlook”. On this basis, we have determined the business model that we hope to be empowered by Ultrain technology in 2020: in a fully competitive industry, establish a mutual trust franchise business model at low cost.

    In order to achieve this goal, Ultrain’s technology needs to be further upgraded from the following aspects in 2020:

    1. Compliance with business compliance requirements: In recent months, various ministries and commissions have issued normative guidelines related to blockchain technology, such as the “Financial Distributed Ledger Technical Security Specification” issued by the Central Bank. These specifications will become the basic threshold for the application of enterprises in the future. In order to meet the requirements of these specifications and achieve commercial compliance, Ultrain needs to conduct further research and development in many aspects;

    2. Consensus innovation: The franchise business model has two characteristics, one is that there are many franchisees, and the other is that the geographical distribution of franchisees is very scattered. This mainly brings a variety of technical challenges, including the different network environments of franchisees, and the need for users to automatically adapt to different networks without perception. There are many network nodes, and the online time of franchisees is not fixed. How to maintain the stability of the blockchain network in the face of a dynamic network. As an open network, how to ensure the security of the network; these aspects are the technical challenges we need to solve this year;

    3. Blockchain privacy protection: In the business environment, privacy protection is the bottom line requirement for system operation. The “Personal Financial Information Protection Technical Specification” issued by the central bank at the beginning of this year can be used as a reference. Ultrain has a deep accumulation of blockchain privacy protection solutions. This year we will form a commercial solution to export and provide services;

    The above are the three technical routes of Ultrain in 2020. We have further divided this technical route:

    替代文字

    替代文字

    替代文字

    替代文字

    The above is the technology roadmap of Ultrain in 2020, which contains a number of world-leading technological breakthroughs. We will further publish the technical implementation details at each step and share our progress with you. Hope that Ultrain's breakthrough in technology can contribute to the commercial landing of blockchain technology.

    posted in Technology read more