Awesome-Mirrors/awesome-blockchain
1
0
Fork 0
mirror of https://github.com/yjjnls/awesome-blockchain.git synced 2024-10-01 00:45:35 -04:00
Code Issues Packages Projects Releases Wiki Activity

update

Browse Source
This commit is contained in:
yjjnls 2018-04-03 23:00:09 +08:00
parent b960b49581
commit 4eea669548
1 changed files with 4 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
Extesnsion/中钞可信登记开放平台白皮书.md
View File

@ -145,7 +145,7 @@
  合作方对用户进行身份认证时即生成了一个用户合约，该合约是后续区块
链业务的交易载体，用户持有的密钥是该用户合约的操作钥匙。如果用户持有
的密钥丢失，可以提供必要的身份证明向合作方申请密钥重置。 密钥重置后，
用户合约的地址和持有的数字凭证不变，变化的仅是用户持有的操作钥匙。
用户合约的地址和持有的数字凭证不变，变化的仅是用户持有的操作钥匙。
  为了防止合作方管理人员滥用职权伪造用户意愿修改合约密钥造成纠纷，
BROP 身份组件要求在每一次重置用户密钥时， 合作方都必须将本次修改涉及到
的用户的申请材料和认证材料在 BROP 上存证。 如果合作方无法提供用户的申请
@ -236,14 +236,14 @@ OPCODE 计算的 GAS 系统。 BROP 仅针对交易量和数据量两项对平
* 配额点数分配
  通常情况下平台的交易由合作方完成，因此各合作方是配额点数的主要消
耗者；同时终端用户也存在发起交易业务的情况，因此终端用户也会在某些情
况下存在配额点数需求。
况下存在配额点数需求。
  BROP 将向各个合作方周期性地分配一定数量的配额点数。终端用户也会根
据业务上限周期性获得系统分配的配额点数，如果某用户恶意发起大量碎片交
易其配额点数很快会消耗完。
* 交易配额计量
  每次交易发起时，交易方需要向系统支付预定数值的配额点数。交易所需
的配额点数与交易复杂度和附带数据量有关。 配额点数不足时，记账节点拒绝
该交易打包。
该交易打包。
  注： BROP 提供链外数据托管服务，其服务存放的数据量与链上配额点数无
关，不在本白皮书的讨论范围内。
@ -324,7 +324,7 @@ BROP 平台中某一个操作步骤出现了法律纠纷，参与方有权获得
#### 4.2.1. 统一身份鉴权
  场景痛点：目前尚不存在一个公用的身份鉴权平台，各个应用方无法对第
三方背书的身份信息完全认可；监管方也很难在跨应用前提下对不同的用户的
征信信息、资产信息进行评估。
征信信息、资产信息进行评估。
  基于 BROP 的解决思路： 某身份认证机构对个人用户和企业用户进行链外
KYC，对其身份信息进行摘要存证；合作方选择信任该身份认证机构， 当合作方
需要了解该个人用户的身份信息时，该身份认证机构在用户同意的前提下将用