Zhuang's Diary

Ewasm实施说明

Posted on 2019-09-09 Edited on 2020-11-02

概念介绍

Hera 是 ewasm（revision 4）虚拟机的 C++版本，对接了 EVMC ABIv6。Hera 目的是利用各种 wasm 的后端，为 ethereum 提供服务。Hera 已经在 aleth 和 geth 上被测试过了。同时，Hera 支持各种匹配于 EVMC 的客户端。

ewasm 是以太坊系的 WebAssembly (Ethereum flavored WebAssembly)，目前的版本是 Revision 4。ewasm是使用WebAssembly确定性子集重新设计的以太坊智能合约执行层。

使用WebAssembly作为智能合约的格式可以获得以下好处：

近乎原生的智能合约的执行速度
使用许多传统编程语言（如C，C ++和Rust）开发智能合约成为可能
WebAssembly庞大的开发人员社区和WebAssembly工具链

EVMC 是以太坊虚拟机（EVMs）和以太坊客户端（如Geth）之间的低级别ABI。在EVM侧，它支持经典的EVM1和ewasm。在客户端（如Geth）侧，它定义了EVM实现访问以太坊环境和状态（state）的接口。

ewasm实施设计1：Hera + geth

创世块配置如下：

{
    "config": {
        "chainId": 1337,
        "homesteadBlock": 0,
        "byzantiumBlock": 0,
        "constantinopleBlock": 0,
        "eip150Block": 0,
        "eip155Block": 0,
        "eip158Block": 0,
        "ewasmBlock": 0,	//**odyssey划重点**
        "ethash": {}
    },
    "nonce": "0xdeadbeefdeadbeef",
    "timestamp": "0x00",
    "parentHash": "0x0000000000000000000000000000000000000000000000000000000000000000",
    "mixhash": "0x0000000000000000000000000000000000000000000000000000000000000000",
    "difficulty": "0x40",
    "gasLimit": "0xfffffffffffffff",
    "alloc": {
        "0x7eff122b94897ea5b0e2a9abf47b86337fafebdc": { "balance": "10000000000000000000000000000000000" }
    }
}

Build geth with EVMC，编译带有 EVMC 的 geth

从目前最新的版本 geth 1.9.2 with EVMC 6 support 下载代码。其内已经有 Linux-amd64 的可执行文件，版本基于 geth1.9.2，在 ubuntu 等 linux 系统中可以直接运行。

也可以进入到代码中自行 build：

1 2	> cd go-ethereum > make geth

将 Hera 编译成为一个共享库文件

> git clone https://github.com/ewasm/hera -b v0.2.4
> cd hera
> mkdir build && cd build
> cmake .. -DBUILD_SHARED_LIBS=ON     //该步骤前可能会需要执行 git submodule update --init
> cmake --build .

使用步骤 1 中的创世块配置文档 geth-config.json

1	> ./build/bin/geth --datadir /tmp/ewasm-node/4201/ init geth-config.json

运行 geth 与 Hera

> ./build/bin/geth \
--vm.ewasm="/path/to/libhera.so,metering=true,evm1mode=fallback" \
--datadir /tmp/ewasm-node/4201/ \
--rpc --rpcapi "web3,net,eth,debug" \
--rpcvhosts="*" --rpcaddr "0.0.0.0" \
--rpccorsdomain "*" \
--vmodule "miner=12,rpc=12" \			//在 odyssey 中不必使用
--mine --miner.threads 1 \				//在 odyssey 中不必使用
--nodiscover \
--networkid 1337

另外 Wagon 作为WebAssembly-based Go interpreter也是可用的。但是https://github.com/gballet/go-ethereum项目年久失修。即使是下面的方式也不建议使用的。

> go get github.com/ethereum/go-ethereum
> cd $GOROOT/src/github.com/ethereum/go-ethereum
> git remote add gballet git@github.com:gballet/go-ethereum.git
> git fetch gballet add-ewasm
> git checkout add-ewasm

架构图如下，请参考：

参考链接==>

Ewasm public testnet : https://github.com/ewasm/testnet
WebAssembly 介绍 : https://willzhuang.github.io/2018/07/26/WebAssembly-%E4%BB%8B%E7%BB%8D/

认识DAO

Posted on 2019-09-01 Edited on 2020-11-02

介绍

人类一直在不断发明组织和增加组织的新方法，从核心家庭，部落，国家，企业到全球经济。到目前为止，最先进的组织—互联网打开了大门，在全球范围内进行实时信息交换，但互联网缺乏通用协调的经济手段和全球同步生产。区块链通过提供可靠的，开放的和可编程的账本系统，进而产生分布式自治组织（DAO）。
DAO是开放的，自组织的网络，由加密经济激励和自执行代码协调，围绕共同目标进行合作。在网络效应的推动下，DAO提供了适度的模式激励用于生成开放和可共享的资源（例如开源代码和音乐文件）。随着在更加开放的资源中创作，DAO可以无限扩展，同时保持其一致性和连贯性，并且在许多案例中胜过现有的公司结构。 DAO吸引了区块链领域的顶尖人才，对创造更高效，更有弹性的组织努力着。尽管如此，到目前为止他们还缺乏成功部署关键要素，特别是适当的分布式治理体系（decentralized governance system）。
DAOstack是DAO的操作系统。有了DAOstack，成千上万的开源创作者可以联合起来生产分散式应用程序（DApps），同时将产品中的所有权分配给有价值的贡献者。人们可以合作拥有和管理排名系统，与TripAdvisor或YouTube展开竞争。自治网络可以进行集体投资或保险基金。我们相信DAO将从根本上改变人们组织的方式，从初创公司到公司，非营利组织甚至民族国家。 DAOstack开发了所需的基本元素实现向未来的过渡。
我们将描述DAO的未来：一种不对称的，反竞争的，可扩展的合作（将来定义如下）。后面的内容将探讨区块链，特别是DAO治理的主题。

良好组织和协调大量个人的能力是最大的力量和社会驱动力之一，经历了数千年的不断演变。在本章中我们将描述当今传统组织面临的挑战，以及一种新的可能形式的网络组织：DAO。

传统组织

代理商的合作提高了其对外部竞争市场力量的效率。这是公司的基本起源以及组织希望发展的原因。但是，协调代理商随着组织的发展需要增加协调成本，这就是组织无法无限期发展的原因。
在组织发展时，组织需要更加严格的结构，因此面临越来越大的挑战：a）保持对快速变化的条件的敏捷性；b）保持利益，信任和利益的一致性，以及其成员之间的互动。简而言之，组织越大，所需的内部摩擦就越难应付；组织越小，内部的摩擦也越小，外部竞争就越大。公司的实际规模通常是这两种力量之间的最佳平衡点。
偶尔，新技术或范式转换可以减少协调成本，将组织的规模和效率提升到新的水平。它触发了机构内部和机构之间的过渡工作和业务，以及此后的社会变革，就像众包和互联网本身被发明时的情况一样。
互联网允许在全球范围内进行开放，实时和点对点的信息交换。因此，互联网媒体已经比传统媒体更具有可扩展性，而且速度很快同化了后者。但是，互联网本身并不支持开放的，点对点的价值交换和通用协调，因此限制其推动全球合作的潜力。

区块链

区块链是第二次互联网革命，为信息和媒体互联网在价值和商业方面做出了贡献。通过解决信息信任问题，它可以实现前所未有的人群协调水平。从而形成分布式自治组织（DAO）的技术基础。 DAO是一种可扩展，自组织合作的新形式，由区块链运营的智能合约相协调。笔者认为DAO对未来商业大有希望，尽管围绕这一主题的区块链社区有很多贡献，但DAO的运作基础仍然缺失，成功的治理体系仍然处于探索的初期。

代理商

DAO的构建块是聪明的公司或代理商（我们将交替使用这些术语）。一个智能代理是一个原子治理单位，通过智能合约进行管理和运营区块链。它有自己的令牌（与公司资源的利益相关），自己的声誉系统（与公司事务的可信度和影响力有关），以及自己的治理体系（其“章程”编码在智能合约中）。
嵌入在智能合约中的治理协议可以是任何人都可以想到的。一个简单的例子是基于提案的治理系统，对所需的提案进行是/否多数表决批准和执行（这成为智能公司的单一行动）。提案可能与令牌有关，例如，分配和投票可以由选民声誉加权。在启发式可视化中，它可能如下所示：

实心球代表公司的代理商；他们与中心的距离反映了他们的影响力，或者声誉（他们越接近他们的影响越大）；他们的规模反映了他们的本土代币占比（球越大，他们持有的公司代币就越多）。一个代理商建议分配5个ETH
代理A为她修复bug XXX的宝贵贡献。公司代理人投票表决由他们的声誉加权，并且一旦大多数声誉持有者同意该提议，智能合约自动执行其令牌分配。

DAOs

代理商在区块链上运行智能合约。它们遵循无法破解的可验证规则并且只能根据规则本身进行更改。他们可能是也可能不是自治的，这取决于他们选择的治理体系；例如，一个机构可以自行保留另一个机构的决策否决权。

DAO是一个无中心的代理网络，它本身也是一个代理机构，不受任何一点控制。它不是中央管理，代理商之间存在间接协调，在生物学中也称为共识主动性（stigmergy），由激励机制和代码触发。DAO是一个自组织实体，
而且大体上更像是有机体而不是组织。

扩展性

所有传统组织的一个共同因素是”可扩展的“。这意味着随着决策数量的增长，传统组织的效率会越低。自由市场，互联网和基于网络效应的应用程序（如Facebook和Airbnb）都是“超级可扩展”结构 - 随着成员和交互的增长而变得更加有效。有了这个术语，DAO是一个“超级可扩展的组织”，它可以提高效率，敏捷性和可扩展性的自由市场，同时保持创业公司的一致性和追求可扩展任务的能力。

网络拓扑结构

有各种各样的权力下放模式，因此可以考虑各种模式将DAO放入一个机构。考虑DAO的常见方法是组装模式：

在DAO的组装模式中，大量代理在单个决策中进行交互。代理商通过其智能合约，假设声誉和决策权力是公平分配的。尽管是最简单的，但这种模式本身就具有可扩展性，并且对其处理有限制能力，同时保持弹性。

以及联邦模式，由大量的分布式的组织治理合作连接为联邦共同体。

开放组织

目前的世界经济体系是一个基于近似零和或输赢的游戏。通过竞争引发了向最高绩效的演变，但绩效是相对于本地而言最大化而不是全球的胜利。（即，一家公司在自身生存方面做出优化，而不是一个更大的整体在利益方面做出优化。这是非合作纳什均衡的问题。纳什均衡的意思是这样的，在一个博弈过程中，无论对方的策略选择如何，当事人一方都会选择某个确定的策略，则该策略被称作支配性策略。这是一个大规模协调的问题，阻止了
从竞争转向合作的可能。

一个常见的例子是代码；它永远不会消耗，而且相反，眼睛越多，代码越好（也越安全）。与此同时，公司没有动力开源他们的代码，否则他们将不对称地给他们的竞争对手带来好处。在另一方面，显然，如果有十家竞争公司生产类似的产品，他们都可以从中受益，共同生产其产品的共享元素，而不是全部独立生产它们。这个难题可能在制药行业（例如电影《我不是药神》中反应的问题）也最为显着。

知识产权（IP）是将反竞争资源转化为稀缺元素的传统手段，它们可以销售，但它在今天的加速步伐中变得越来越不明智，也越来越不实用。

开放共享资源与当前经济不一致。但另一方面，它是非常大规模的，开放式的协作，并以DAO的基础。为了更加有效，DAO需要激励和奖励共享可重用组件。结果，更多现有的可共享组件将支持增长和DAO的有效性。开放组织是从目前非合作纳什转变的手段，平衡未来的合作国家。但是，DAO将取代现有的公司结构，因为他们更好或更道德，更简单，且更有效。

以上内容来自：https://daostack.io 的白皮书。笔者认为 DAO 会在未来的经济合作模式中占有一席之地。

Hyperledger-Fabric-vs-Ethereum-vs-Odyssey

Posted on 2019-08-28 Edited on 2025-12-29

面向产业的区块链需要解决 B2B，B2C，B2B2C场景的完整解决方案。其中包含：

个人账户&资产管理
节点准入与管理
区块链账本
交易&数据隐私
规模化扩展(跨链)的支持

本人认为以上是区块链特性的硬伤，跨过这样的临界值，才能够大量投入产业应用。至于部署的复杂度，合约的表现力，这些都是程序员可以解决的问题，不构成产业应用的硬伤。

Ethereum中如何实现ACL

Posted on 2019-08-26 Edited on 2025-09-05

需求

在供应链(金融)、个人履历以及各个行业应用中，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-无头电商与中台随想

Posted on 2019-08-19 Edited on 2025-09-05

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更加灵活。一些都是接口，一切都是可描述的。