mirror of
https://gitee.com/BTAJL/repchain.git
synced 2024-12-02 11:48:10 +08:00
RepChain常见问题列表
This commit is contained in:
zhengls
Gitee
parent
5ba96c8337
commit
bb5eee9189
202
FQA.md
Normal file
202
FQA.md
Normal file
@ -0,0 +1,202 @@
|
||||
## 常见问题
|
||||
|
||||
### RepChain是什么？
|
||||
|
||||
> RepChain(Reactive Permissioned Chain)是第一款采用响应式编程实现的 许可链基础组件，由区块链技术与应用联合实验室、北京连琪科技有限公司 和软件所互联网金融技术研究中心共同研发。组网节点内部和节点之间均采用异步消息交互机制，模块化、松耦合；全新设计的系统架构，突出了响应式、松耦合、轻量级、协同性共识、合约分级部署、运行状态可视化等特点；在身份准入的基础上建立安全信道，采用协同性共识代替竞争性共识，提高了交易的实时性和交易通量。目前最新版本是1.0。
|
||||
|
||||
### RepChain有哪些特征？
|
||||
> RepChain具有标准化、模块化、可视化三个特征。
|
||||
（1）标准化：尽可能采用经过工程实践认证的标准组件，在基本功能稳定，满足工程实施的基础上大幅减少代码量，方便他人改造使用；
|
||||
（2）模块化：节点间以消息格式交互，节点内部以状态驱动，具备模块替换的可行性；
|
||||
（3）可视化：将复杂的交易传播、共识入块的过程直观化。
|
||||
|
||||
### RepChain特点介绍？
|
||||
> 适合分布式环境：相对于非响应式实现在分布式环境下具备更好的韧性（包容各类分布式异常）和弹性（通过Actor的集群模式动态伸缩算力）；
|
||||
|
||||
> 工程友好：采用成熟的Scala语言作为合约开发语言，支持在ScalaIDE下进行合约的单元测试和在线仿真调试，开源代码覆盖了联盟链实施的常用功能，且提供了详尽的功能测试用例；
|
||||
|
||||
> 模块化：组网节点间以消息格式交互，节点内部以状态驱动，方便根据场景需要替换模块；
|
||||
|
||||
> 合规性：支持国标和国密两类加密套件，支持集成实名认证；
|
||||
|
||||
> 标准化：采用的组件均为规范的标准化开源组件，支持相关组件的平滑升级；内部各模块的调用支持标准格式的日志输出；
|
||||
|
||||
> 可视化：通过实时状态图将节点间复杂的交易传播、共识入块的过程直观化。节点内部各模块的日志输出可作为主流实时图表的数据源，直观分析性能细节。
|
||||
|
||||
|
||||
### RepChain适用场景有哪些？
|
||||
|
||||
> 适用于企业级应用，比如金融、医疗、电子存证、司法存证、房地产、保险、银行、数字资产、物联网、供应链等领域。
|
||||
|
||||
### RepChain的开发历程？
|
||||
|
||||
> 2017年5月开始第一行代码
|
||||
|
||||
> 2018年5月在贵阳数字博览会发布V0.7版本，12月发布V0.8版本（含国密算法）
|
||||
|
||||
> 2019年5月在贵阳数字博览会发布V1.0预览版
|
||||
|
||||
### RepChain的架构是什么？
|
||||
|
||||
> RepChain系统共分为六层，从底层到上层分别是数据层、网络层、共识层、合约层、API层、监控层。RepChain是在分析和比较了比特币、以太坊、fabric、EOS的架构设计，根据设定的目标和定位，全新设计。
|
||||
|
||||
### RepChain基于什么组件实现？
|
||||
|
||||
> RepChain的实现采用了Actor模型，表现出良好的容错性/韧性，同时易于对系统的瓶颈环节进行算力调整。例如，在RepChain的性能优化过程中，发现请求背书环节存在比较严重的阻塞(耗时约120ms)，拖累了整个系统的TPS(Transactions Per Second,每秒交易数)。因此决定将背书请求的处理从原来的单Actor实例串行改为多Actor实例并行：将负责背书请求的模块调整为负责调度的Actor和负责背书处理的子Actor；同时保持对外服务的背书请求消息格式不变，子Actor对背书请求消息的处理逻辑不变。改进后背书处理耗时降低了40ms，系统的TPS指标提高了60，改动的代码数不到300行。而同类系统采用Kubernetes等工具在容器级别进行算力调度，难以实现类似的模块/子模块级别的细粒度算力调整。
|
||||
|
||||
### RepChain性能如何？TPS多少？
|
||||
|
||||
> RepChain 1.0通过了中国信息通信研究院“2019可信区块链测评”功能测试和性能测试，TPS为1800。
|
||||
|
||||
### RepChain目前正在使用的应用场景有哪些？
|
||||
|
||||
> 目前，RepChain基础组件已经应用到存证溯源、供应链升级、消费积分、物联网溯源以及房地产租赁等领域。
|
||||
|
||||
> 基于RepChain的图片版权应用为数字图片的版权登记保护提供了一种基于区块链的解决方案。用户可以根据图片密码学哈希值、图片元数据以及个人信息，使用客户端程序生成版权登记交易，并向联盟链节点发起版权登记请求，以调用数字版权登记智能合约方法，在区块链可信数据中存储相应版权登记记录，从而实现无单一中心控制的数字图片版权存证和举证服务。
|
||||
|
||||
> 基于区块链技术的电子证据存证应用是中科院软件所和中科实数共同研发，旨在利用区块链的智能合约实现存证和检索等功能，同时通过区块链的可追溯、不可篡改特性实现联盟数据的可信共享，促进多方信任。RepChain为传统集中化的电子证据存证服务提供防篡改和可追溯的特性，使其存证要素可被验证从而保护了电子证据的完整性，并奠定了其可采用性的基础。目前已有2000多万交易，1500多万个数据块。
|
||||
|
||||
> 面向房地产租赁和交易的区块链系统是中科院软件所和福建中电网络科技有限公司共同研发，通过打造房地产线上租赁、交易与管理平台，研究区块链在房地产领域的数据生产、采集、处理、传输、存储、挖掘利用、收益分配等各环节的共享与可信流转，探索并实践利用区块链技术促进房地产行业健康发展的新途径。
|
||||
|
||||
> 清源链是基于 RepChain 的医疗废弃物溯源处置系统，由中科院软件所和中科软科技股份有限公司共同研发。清源链旨在利用区块链的智能合约实现医疗废弃物的存证溯源等功能；同时，通过区块链的可追溯、不可篡改特性实现联盟数据的可信共享，促进多方信任。目前已有500多交易，500多个数据块。
|
||||
|
||||
> 基于RepChain的物联网河流生态数据监测系统，在贵阳乌当区普渡河试点运行，在整条普渡河流域的 8 个点位上部署低功耗物联网的水质传感器，并连接区块链集群，将检测到的数据实时上链。根据不同数据提交的签名和时间戳，可以溯源到每一个物联网设备区域，使水质生态责任明确，生态变化情况和污染预警有据可查，有迹可循。
|
||||
|
||||
### RepChain是否有推荐参考的应用？
|
||||
|
||||
> 区块链数字不动产证书应用获得“2019可信峰会”潜力案例，可供参考；
|
||||
|
||||
> RepChain提供区块链基础应用Base App，实现无侵入的方式与现有生产系统的账户管理整合，快速实现为账户增加密钥对申请绑定、交易签名与验证等功能。方便区块链应用实施者直接复用其提供的功能，也可在其源代码的基础上快速开发自己的应用。
|
||||
|
||||
### 基于RepChain的应用开发有什么不一样？
|
||||
|
||||
> RepChain提供应用接口，智能合约不一定必须，RepChain轻量的好处是帮助开发者更方便的进行更改。不一样的地方是可以“做加法”，给开发者提供最简单的模块并给出示例，根据自身场景来进行扩展，RepChain本身是模块化，“做加法”是本质特征，开发者可以根据应用场景来更改RepChain代码，方便开发者的使用。在开发应用时也要考虑到密码学、证书等问题，跟传统存在区别。
|
||||
|
||||
### RepChain的国密算法是什么？
|
||||
|
||||
> RepChain国密支持组件由北京中宇万通科技股份有限公司（简称中宇万通）提供，中宇万通长期专注于国密算法的应用研究，并且通过了大量支持国密算法的产品认证，包括支持签名验签类的SRJ 1707、支持时间戳算法的SFJ1706、支持GMSSL协议的 SJJ1505、支持移动安全接入的SJJ1812等产品算法。
|
||||
|
||||
### RepChain设计特点是什么？
|
||||
|
||||
> RepChain模块化设计具备高内聚低耦合的特点，每个组网节点对应一个ActorSystem，主要功能模块均封装为Actor，包括API服务、合约执行、共识策略、事件订阅，去掉一个Actor不会影响其他Actor之间的消息交互，也不会产生编译依赖的问题，便于进行系统调整。
|
||||
|
||||
### RepChain的合约机制？
|
||||
|
||||
> RepChain的合约实现中，通过运用成熟的Scala类反射机制、动态类编译、类加载技术、actor模型的透明分布式调用,本合约容器具备以下技术特性：
|
||||
采用图灵完备、经过工程化实践检验的Scala语言作为合约开发语言；
|
||||
采用Scala IDE或者其他支持Scala调试的通用IDE作为合约调试IDE；
|
||||
支持合约的单机调试、分布式部署、动态即时编译和加载；
|
||||
根据合约调用的性质，决定串行或并行地执行合约调用；
|
||||
按照合约的信任级别，可选择进程内部署、跨进程部署或者跨主机部署；进程内部调执行效率，跨进程或跨主机部署强调安全隔离；
|
||||
执行合约方法时采用严格的授权验证，杜绝越权行为。
|
||||
|
||||
### RepChain的共识机制？
|
||||
|
||||
> 采用兼顾实时性和安全性的CFRD算法(consultation-free random draw algorithm with distributed environment,简称CFRD)，完成区块的输入共识和输出共识.既照顾到交易的实时性要求，又能在一定程度防止节点串通作弊；输入共识对入块的交易顺序达成一致，输出共识对交易顺序执行的结果达成一致。
|
||||
|
||||
|
||||
### 在linux 系统中部署运行命令
|
||||
|
||||
执行如下命令：
|
||||
|
||||
1.下载依赖项
|
||||
sbt
|
||||
|
||||
2.编译文件
|
||||
compile
|
||||
|
||||
3.运行
|
||||
java -Dlogback.configurationFile=conf/logback.xml -jar RepChain.jar 121000005l35120456.node1
|
||||
|
||||
后台自动运行：
|
||||
nohup java -Dlogback.configurationFile=conf/logback.xml -jar RepChain.jar 121000005l35120456.node1 &
|
||||
|
||||
4.打包
|
||||
assembly
|
||||
|
||||
### 密钥对备份问题如何处理？
|
||||
|
||||
> 建议对根证书/密钥对，每个节点的证书/密钥对
|
||||
|
||||
### RepChain针对跨链如何处理？分别在本地或者内网做好备份，防止丢失，根密钥对一旦丢失就无法对由其注册的共识节点提供密钥替换服务，节点密钥对丢失则无法对由其注册的用户密钥对提供密钥替换服务。
|
||||
|
||||
> 跨链不同合约中读取账户已实现
|
||||
|
||||
### 在分配物理机的资源时有时会出现资源泄漏问题？
|
||||
|
||||
> 建议在分配资源时尽可能多，内存建议2048M
|
||||
|
||||
### RepChain的证书和节点数不一致时交易时间有延迟？
|
||||
|
||||
> RepChain/jks目录下信任证书个数和节点个数需保持一致
|
||||
|
||||
### RepChain在首次下载代码之后，直接打包会出现创世块不能运行的情况？
|
||||
|
||||
> 打包之前在Scala IDE中运行一下RepChain，以便生成scala文件，比如sha2d85b1d0509c3afe12b0edcd964f7f00a1319727989e81e7131298422f7416de.scala
|
||||
|
||||
### 在配置文件repchain/conf/system.conf中如何设置共识节点和非共识节点？
|
||||
|
||||
> vote_node_list这个项是必须的配置，配置内容是可以参与的共识节点的别名，没有配置的节点不是共识节点
|
||||
|
||||
### 在一个区块链系统中如何添加新的节点？
|
||||
|
||||
> 将新的节点设置为非共识节点，等数据同步完成之后再设置为共识节点
|
||||
|
||||
### 1.0预览版有哪些新特性？
|
||||
|
||||
> 1.Protobuf定义
|
||||
|
||||
> 相对于第一版进行了精简，系统字段所占空间大幅减小；
|
||||
|
||||
> 块结构体加入了高度，方便用户同步数据；
|
||||
|
||||
> 新增了部分字段用于支持新增的合约功能。
|
||||
|
||||
> 2.合约模块
|
||||
|
||||
> 2.1生命周期管理
|
||||
|
||||
> Deploy：部署合约的时候，支持合约使用别名，以及指定版本号，支持用户的升级，允许合约部署指定其在invoke时采用并行方式/串行方式执行；
|
||||
|
||||
> Invoke：通过合约别名和指定版本号，即可调用相应合约，增加了对并行invoke合约方法的支持；
|
||||
|
||||
>setState：支持合约的禁用，启用，相应状态在该条交易入块之后生效。
|
||||
|
||||
> 2.2引入法律描述
|
||||
|
||||
>支持合约的开发者，在合约中对合约的执行流程以及结果进行法律描述，用于责任的界定。
|
||||
|
||||
>不再返回预执行结果给合约调用方，只返回执行是否成功调用。
|
||||
|
||||
>一律采用Scala语言作为合约脚本，不再支持Javascript合约脚本。
|
||||
|
||||
>支持跨合约读取KV。
|
||||
|
||||
>底层接口引入日志，即合约开发人员也可以将日志引入到合约中。
|
||||
|
||||
> 3.日志模块
|
||||
|
||||
> 3.1日志分级
|
||||
|
||||
>业务日志与系统日志分开管理，可根据业务需要进行配置。
|
||||
|
||||
> 4.账户和证书管理
|
||||
|
||||
> 4.1账户证书分离
|
||||
|
||||
> 账户和证书分开管理，通过对应的credit_code来进行关联，一个账户可以拥有多证书。
|
||||
|
||||
> 5.系统效率、稳健性的提升
|
||||
|
||||
>对块与交易大小在API层进行限制，避免无效交易造成算力浪费
|
||||
|
||||
>对节点之间方案进行了重新设计，同步更稳健
|
||||
|
||||
>背书、共识、出块进一步细粒度并行化，执行效率更高
|
||||
|
||||
>代码中在对非Protobuf对象进行序列化时，采用更高效的序列化实现
|
||||
|
||||
>系统启动时加入了数据自检，对块的完整性进行检查
|
||||
|
||||
>使用最新稳定版本的scala2.12和akka2.5.22，其他依赖库也进行了更新
|
||||
|
||||
Loading…
Reference in New Issue
Block a user