hyperledger-fabric-vs-Ethereum-vs-Odyssey
面向产业的区块链需要解决 B2B，B2C，B2B2C场景的完整解决方案。其中包含：
个人账户&资产管理
节点准入与管理
区块链账本
交易&数据隐私
规模化扩展(跨链)的支持
本人认为以上是区块链特性的硬伤，跨过这样的临界值，才能够大量投入产业应用。至于部署的复杂度，合约的表现力，这些都是程序员可以解决的问题，不构成产业应用的硬伤。
Ethereum中如何实现ACL
需求
在供应链(金融)、个人履历以及各个行业应用中，ACL（Access Control List）是共同类的需求。
写管理
OpenZeppelin，Roles.sol 可以使用，搭配 ERC721 合约 使用，处理生成和销毁数字资产功效加倍。但是数据写在区块链上之后，即使使用了 private 关键字也是可以被用户读取的。
以上方法只实现了用户的 写权限控制，无法实现用户的读权限控制。
读管理
思路简介：
a) 客户端 AES 加密原文（shared data）；b) 密文(encrypt(shared data))如果过大则存放于某云数据库，其他用户也可以访问到云数据库，也可以直接存放于ethereum 上，如 Tx 的 extraData 或者 state 中；c) 验证用户符合条件，如 role，policy或者address的要求时，data owner 将 encrypt 的秘钥经过用户（data user）的 pk 加密后， 通过 event 传递给到用户（data user）
详细参加：Multi-Authority Attribute-Based Access Control with Smart Contract
以下是论文中的详细说明：
Architecture
System target
Here we present a concrete example. Suppose an data owner in the Computer and Information Sciences Department at the University of Delaware specifies access policy W to be [UD, PhD Student, Gender#] for accessing encrypted research meeting notes, and we have student Alice’s attribute list SAlice = [UD, PhD Student, Female], and student Bob’s attribute list SBob = [UD, Master Student, Male]. As a result, Alice can access the corresponding encrypted research meeting notes, while Bob cannot because he is an Master student. Notice that the Gender# attribute indicates that either gender satisfies the access policy.
Participants
• Data Owner (DO): A DO is an entity (e.g., person, organization, or process) who owns the data to be shared. A DO actively specifies access policies for the data it shares.
• Data User (DU): A DU is an entity who wants to access data shared by DOs. A DU actively seeks access authorizations from DOs.
• Shared Data (SD): An SD is a piece of data owned by a DO, and can be accessed passively by authorized DUs.
• Attribute Token (AT): An AT is a credential representing an attribute that a DU possesses.
• Attribute Authority (AA): An AA is a pre-verified and authorized node in Ethereum who issues ATs to qualified DUs who possess the corresponding attributes.
Workflow / Timeflow
Headless-Commerce-无头电商与中台随想
Headless Commerce是一个有趣的名字，它是近一年国外电商行业的时髦术语。国内还不怎么流行这种叫法，但与其对应类似的概念实际上在中国也是漫天飞舞，这就是“API化”和“中台”说法。想到中台的火热，我也随手记下这篇文章，聊聊无头电商和中台。
什么是无头电商？
Headleass Commerce可以翻译成无头电商，或断头电商，核心概念就是将前台展现和后台服务进行解耦的一种架构。后台以API的方式提供服务，前端展现层与后端分离。没有前端表现层（头），剩下的就是无头电商了，剩下的就是一堆API接口。
写过代码的程序员都很容易理解，这不就是前后端分离，或面向服务架构(SOA)么？为什么这么简单的事情，会成为电商行业的噱头呢？其实，这个事情后面有很多深层次的原因，有商业原因，有电商演进历史，有生态原因，有品牌主新需求等等。
为什么会发生这种变化?
有几个事情比较重要：
- 品牌主建立自有电商的需求
国内外电商平台虽然都已经寡头化，美国有亚马逊，中国有京东淘宝，很多品牌主依旧努力建立自有电商渠道，不断突围。
品牌主建立自有平台可以加强自有数据的把控能力，直接与消费者进行互动，保证独有体验。
- 电商体验的多样化
电商不在是一个简单Web端，电商行业出现很多新触点：语音购物，无人超市，场景购物等，前端变得更加丰富多样
底层的基础能力相对稳定，底层可以利用API确保稳定
- 品牌直接面对消费者（Brand Direct To Consumer)
很多互联网品牌通过创新的电商方式直接面对消费者，消除传统的中间环节（零售商，批发商等）
一些私域流量给DTC创造了很多创新机会，最后这些创新场景都需要落地电商平台上。
- 电商平台的演化
- 一体式的电商解决方案：从交易到内容，往往是一家巨型供应商提供，比如Oracle , SAP， WordPress等
- 内容和交易能力的一些分离，出现了CMS或DXP的独立功能区域
- 无头电商：以API为基础的构建方式，前后端分离，通过API支持更广泛的生态
这种无头商务平台脱离了通常模板化的系统前端，允许开发人员在任何类型的框架中为产品和服务创建各种接触点。这样，后端开发人员就可以灵活地创建和使用应用程序编程接口（API），以便交付给任何类型的设备，而不仅仅是标准屏幕。
无头商务与传统商业有什么区别？
传统平台为客户和业务提供了模板化的体验，缺少自由风格的发挥空间，通过无头商务，可以更好地控制商务平台、客户业务和用户体验。
结论
无头电商的好处本质上都来源于前后端的解耦，面向服务和API的架构。后端可以聚焦在沉淀，前后端可以利用API进行交互，以实现更多的应用场景。
- 无头商务是迎接物联网时代（IoT）而创建的对应一些新零售场景，特别是没有任何屏幕的场景，如何通过语音，视频，手势等方式与消费者完成商业互动，其中也包括在户外，汽车等不同场地。
- API 是数据流动的管道
无头电商也是未来数据收集，分析，管理的技术架构的基础。传统的单体电商产品，往往不能实现数据的灵活对流。 - 快速发布
各模块的解耦使得各个模块可以独立升级和发布，各个模块可以采用微服务技术独立发布，只需要保持接口的稳定和兼容。新的功能可以通过增加新的接口，新的场景可以驱动这些新接口的集成。例如，我们需要更换支付服务商，我们只需调用一个新的接口实现者就行，原则上不需要大更改，所有上层应用都不受影响。 - 个性化
无头电商是模块化和灵活的，各个模块API可以进行灵活的组合，封装，二次开发等。很多个性化的策略可以灵活应用在无头电商的各个环节当中。例如，消费者画像也可以作为标准模块，提供给各个模块使用，最大程度复用沉淀的洞察。 - 扩展性和稳定性
稳定性，可扩展性和性能对电子商务系统非常重要，因为它们可以直接影响客户的购买行为。如果出现意外的后端故障，如果后端和前端断开连接，后者仍然可用。后端和前端可以独立地进行水平扩展和垂直扩展。
无头电商和中台
说到这里，无头电商和中国热火朝天讨论的中台（Platform）的理念非常类似：大中台，小前台；
大中台：本质上是沉淀能力，利用API提高复用性；小前台：本质上是快速迭代和试错。这个逻辑其实是和Gartner2015提出的Pace-Layerd 应用战略是一致的，当时Garnter根据系统的变化速度分为 “创新型” ，”差异型”，”稳定型”几种。
数据中台其实就是保持接口稳定的一个系统，支持快速创新的业务层。
中台的一些困惑和随想
在中国，中台已经流行几年了，仔细想想，中台本质也是一种无头。无头电商是中台概念在一个具体行业的应用。沉淀和复用是很多公司的不同阶段都会碰到的，中台战略是解决这个问题的某种形式。很多大大小小公司开始组建中台攻坚团队，我与很多朋友都聊过中体的经历，大大小小都会碰到一下一些困惑。例如，一个公司在推进中台战略中，单点登录是唯一成功的案例，其它中台能力的推广都是很难，每个业务线都有自己研发，不喜欢别人轮子。
1) 中台和前台的界限无法界定清楚。中台实现两个能力，一个是沉淀，另外是复用； 二者相辅相成。前台更加面向客户，他们更加容易最快速度创造客户价值和商业价值。
如何衡量这种花费是否合理？ 一种衡量的方法是：对每个新业务，评估一下中台支持的粒度和程度，如果对于中台的范畴，大家都没有太大歧义，这么这种解耦可能是合理的。如果对于每个新业务，大家都要对范围界定进行激烈讨论，那么大家还是需要一个更加清晰的中台定位。
2) 中台的成功无法衡量和量化
那么如何衡量中台的成绩和成功呢？很多时候这个成绩是没有办法衡量的，但是无法量化的东西，是无法改进的。因此，很多中台的战略都是至上而下的组织形态优化。
具体量化的时候，我们常常有两个思路：a) 中台能力被使用了的范围和深度 ，例如API调用次数，业务使用量，依赖强度等；b) 中台帮助那些业务提升了效率和效益，提升比例等。量化这些指标常常是短期的行为，中台建设也包括一些创新的投资，以及中长期的数据能力沉淀。
3) 产品经理在中台战略的新挑战
大多产品经理喜欢参与2C的产品设计，小一部分产品经理深入2B的产品设计。中台涉及很多技术逻辑，涉及到业务底层实现，涉及到公司多个部门的协同共赢，能够胜任这种角色的产品经理，少之又少，大部分都是由研发主管兼任，或者是项目经理类似角色担当。
中台产品经理比较靠近2B/2D的产品经理，但是更加面向内部多种业务，面向综合效率提升，面向技术架构，也需要很强的商业化的思考。
4) 数据中台越来越重要
大部分公司都有独立的数据平台团队，但各业务线对数据都有自己的解读。在每一个时刻，数据中台需要有自己清楚的定位，这个定位需要让所有业务都清楚了解。如果定位有任何变化，这种变化需要提前通知到各个业务线。
现实中，各个业务线都会发展自己的数据应用能力，数据分析能力，这些分析需要定期的沉淀到数据中台。
5) 中台需要面向开发者，与理解数据逻辑的业务人员的
中台不是华丽的界面和装修，而是底层的脊梁和砖头。中台的能力，必须由业务团队使用（逻辑上理解），程序员使用（利用API调用）。
如果中台直接面向业务的运营，很可能是不成功的。因为，运营很多时候具有快节奏的变化，缺少稳定性，运营平台更像是一种中台的上层应用。另外，运营在使用中台时候，缺少工程师对于API的一些理解，也不利于中台的接口完善和发展。
前台团队中有程序员，才能最大程度发挥中台的作用。
6) 中台是需要运营的，面向中台服务的技术运营
运营可以成为中台和前台的润滑剂，保证前台和中台之间的顺畅。在一些大型的公司，中台能力甚至需要一些主动的推广，确保整个组织能够真正从中台中收益，并且为中台也做贡献。
无头电商的技术方案
说了这么多中台，看起来有些跑题了，回到无头电商的一些技术，其中有些技术很多技术中台都可以采用。
1）CMS支持无头电商的产品：
- Contentful (非常流行, 基于API的内容管理系统)
- Adobe Experience Manager (企业级别体验管理平台)
- Amplience (企业级别体验管理平台，支持无头电商)
- Acquia (企业级别体验管理平台，支持无头电商)
- Kentico （中型内容管理平台)
- Sitecore (企业级别内容管理平台)
- Prismic (面向API的CMS)
- Gatsby (基于react的PWA 框架)
- Vuestorefront (基于vue.js的PWA 框架)
- Deity (基于react.js的 PWA 框架)
2）支持无头电商的系统
- CommerceTools
- ElasticPath（用途比较广的电商平台，支持丰富API）
- Moltin（主打API模式的电商平台）
- Magento （2018年5月被Adobe收购，整合在Adobe Commerce Cloud中，支持与Adobe其它软件整合）
- BigCommerce（主打无头电商）
- SAP CX Commerce Cloud （优势在后端 如CRM/ERP等，支持通过API模式与不同的前端整合）
- OroCommerce (B2B的电商平台)
- Spryker
3） 无头电商的API标准：
OCAPI (Open Commerce API)：
这个标准是Salesforce提供的电商API，渐渐成为电商行业的开放标准，Magento，SiteCore等系统能比较好支持这个协议。Salesforce在对接标准和开放程度上走在行业领先地位，这也是大家看好它的重要原因。
JSS(Javascript Services)
SiteCore利用Javascript提供的API能力，SiteCore也越来越开放
**4） 扩展性的前端技术： **
- JAMStack
这是一个非常有趣的架构，企图颠覆传统三层架构：静态元素放在CDN上，动态数据利用Service/API进行交互。JAMstack将复杂问题分解为动态和静态部分。
PWA（Progressive Web Apps)
把网页开发成像本地应用一样的技术，可以媲美原生用户体验，包括离线可用，后台推送等功能。类似微信的小程序技术，只不过PWA是浏览器里的小程序。PWA梦想很美好，现实很残酷。PWA的技术也在被各种平台内的技术所代替。
GraphQL
一种面向API的理想主义查询语言；传统API需要严格规定参数和格式，GraphQL提供了一些API的查询和归一化能力，使得API开发更加方便和具有扩展性。它比REST更加灵活。一些都是接口，一切都是可描述的。
无头电商的缺点
1) 复杂性的增加
单体模式依旧是最简单模式，无头电商将失去这种简单，进入一个复杂的技术世界。幸运的是，现在的软件技术和云技术都可以更好的处理这些复杂度，当然这也涉及到技术思维的升级。。
2) 成本的增加
无头电商的推广和实施往往需要时间和耐心。从经验来看，无头电子商务实施通常会产生成本开销（由于需要更多开发）；集成也会更加复杂 ，其中会涉及到更多的第三方供应商。
那么，如何管理这种复杂度和有效管理成本？有几点可能会有帮助：
1）加强数据团队和云技术人才，增强管理技术复杂度的能力
2）业务驱动的演化路径，一步步的演化系统架构，更好的系统架构要更加快速尝试更多的业务场景
3）积极利用公有云基础架构，少造轮子，持续优化
参考连接：
https://paulnrogers.com/introduction-to-headless-ecommerce/
https://www.sparkred.com/blog/michael-kors-case-study-a-journey-to-headless-commerce/
https://www.ipraxa.com/blog/headless-ecommerce-guide/
https://jss.sitecore.com/features
https://www.bigcommerce.com/blog/headless-commerce/
https://www.degdigital.com/insights/headless-architecture-digital-experiences/
https://www.bigcommerce.com/blog/flexible-headless-commerce-solutions/
https://www.jianshu.com/p/a88b80d88284
作者介绍：欧阳辰，品友互动，CTO，《Druid实时大数据分析》书作者，《构建高质量的软件》译者，超过17年的互联网老兵。
AZTEC-基于ethereum的隐私交易-III-产品设计
产品设计的关键步骤
AZTEC 产品的关键步骤：1）生成 note；2）管理秘钥；3）验证 note
AZTEC中的aztec.js能够工作在浏览器或者手机程序中，生成 proof 大约需要 10ms，非常高效。
1.生成 note
证明（proof）中的保密 Token 需要用到 note。note 在票据登记所（note registry）中登记，proof 也在 note registry 中登记。
生成一个新的 note 需要 owner 的publicKey，所有人使用其地址证明其 owner 的身份，value是 note 中保密 Token 的值：
bobNote1 = await aztec.note.create(bob.publicKey, 100);
2.管理秘钥
每一个 note 都有一个对应的查看秘钥（viewing key）；同时还有一个对应的暂存秘钥（ephemeral key）。暂存秘钥用于恢复查看秘钥，同时 note 的 owner 的 private key 也可以恢复查看秘钥。
在服务器端，恢复查看秘钥并再次发送给到 owner 需要一套完备的管理系统，目前 AZTEC 还没有这样的系统。
在客户端，建议将暂存秘钥加密后保存起来。
3.消费 note
消费 note 使用标准的 Join Split 证明。
1 | const { proofData, expectedOutput, signatures } = aztec.proof.joinSplit.encodeJoinSplitTransaction({ |
kPublic是被转换的 ERC20 Token 的值。负值代表 ERC20 Token 被消耗，且转换为 note；正值代表将 note 兑换回到 ERC20 Token。且遵守kPublic == outputNotes
Join Split证明是自动使用inputNoteOwners: [bob]的私钥来签名交易的。更加严谨的话可以使用confidentialApprove方法，例如：
1 | const signature = aztec.signer.signNote(assetAddress, noteHash, spenderAddress, owner.privateKey); |
最后再使用下面的语句最终消费掉 note：
1 | await privateVenmoContract.confidentialTransfer(proofData, signatures, { |
AZTEC 的交易流程
如图所示，结合借贷 DApp，分析AZTEC的步骤：
1.借贷 ZkAsset
1.1.构建 proof
用 aztec.js 构建 proof。即 proofData：
1 | const { |
1.2.注册 note
proof 可以被 Mint 成为新的 note，
1 | Loan(loanId).confidentialMint(MINT_PROOF, bytes(_proofData)); |
2.结算 ZkAsset
2.1.批准 ACE 合约代表 owner 花费 ERC20 Token
1 | await settlementToken.approve(aceContract.address, value); |
2.2.构建 proof
1 | const { |
2.3.批准 ACE 合约花费 ERC20 Token
1 | await ACE.publicApprove(zkAsset.address, hashProof, kPublic, { |
2.4.转发交易
转发 proof 给到 ACE，proof 中的senderAddress与发起调用ACE.validateProof的msg.sender 需保持一致。
1 | (bytes memory _proofOutputs) = ACE.validateProof(JOIN_SPLIT_PROOF, address(this), _proofData); |
2.5.处理转移指令(Transfer Instructions)
1 | _loanVariables.settlementToken.confidentialTransferFrom(JOIN_SPLIT_PROOF, _proofOutputs.get(0)); |
3.结算贷款处理
3.1.批准结算合约来花费 note
1 | const settlementSignature = signNote( |
3.2.构建 proof
1 | const { |
其中需要takerBid == makerAsk ; takerAsk == makerBid
3.3.终极交易并更新状态
1 | (bytes memory _proofOutputs) = ACE.validateProof(BILATERAL_SWAP_PROOF, address(this), _proofData); |
由此完成了借贷以及结算，同时全部的账目均为保密。
AZTEC-基于ethereum的隐私交易-II-发布至Ganache
项目进展
AZTEC目前已经在 ethereum mainnet 上线PoC，应用于 DAI 与 AZTEC Token 的转换，即从 DAI 的明文 ERC20 到密文 AZTEC note 的转换。
目前 AZTEC 也可以实现独立密文 Token 的发布和使用，完全基于密文的 Join Split 交易证明。
目前如果是 2 个输入note，2 个输出note，保密交易的情况下，在 ethereum 的 gas 消耗大概是 900,000gas。如果 EIP1108 上线了的话，gas 消耗大约在 200,000 — 300,000gas 之间。
示例项目 step by step 发布至 Ganache
1.下载，git clone https://github.com/AztecProtocol/aztec-ganache-starter-kit.git
2.安装，cd aztec-ganache-starter-kit && yarn install
3.复制 account 环境，cp RENAME_ME.env .env
4.通过 **package.json **的 script，配合.env 中的 account 配置，启动 Ganache，yarn start
5.通过 **package.json **的 script，按照 truffle-config.js 中的内容，配合migrations中的发布文件，编译合约并发布至 Ganache，yarn migrate
1 | ➜ aztec-ganache-starter-kit git:(master) ✗ yarn migrate |
第一步 1_initial_migration.js
第二步 2_ace.js。发布 ACE，setCommonReferenceString 方法建立零知识系统的配置文档
await aceContract.setCommonReferenceString(constants.CRS);
通过 ACE 的setProof(proofId, address)方法来设定各个执行证明的合约地址。proofId 为 proof 的类别，从@aztec/dev-utils里面取得定义。address为发布的合约地址
1 | await aceContract.setProof(MINT_PROOF, AdjustSupply.address); |
第三步 3_ZkAsset.js。发布零知识资产（ZkAsset）
1 | // initialise the ZkAsset with an equivilant |
此处共计 5 个参数：
1.aceAddress — ACE 的合约地址；
2.linkedTokenAddress — 零知识资产所代表的公开的 ERC20 Token 的合约地址，如不代表特定 Token 则可设定为 address(0)；
3.scalingFactor — 是表示与代表的 ERC20 Token 的转换比例，此处为 1:1 转换；
4.canAdjustSupply — owner 是否可以修改 note 的 totalSupply；
5.canConvert — 是否可以将保密 note 转换回到公开的 ERC20 Token
测试
1 | ➜ aztec-ganache-starter-kit git:(master) ✗ truffle test |
测试程序位于test文件夹内。