0x 白皮书 (简体中文版)
Will Warren, Amir Bandeali
2017-2-21
翻译： sunhuachuang， Qobit.com
- maker 生成订单的用户
- taker 填写订单的用户
- relayer 交易所原型，接收maker的订单并展示出来, 可以协助taker进行交易
- gas 以太坊中的执行智能合约的费用
我们描述了一个协议，用来在太坊链上ERC20所定义的点对点的代币交易中减少障碍。这套协议目的是成为一种开放的通用标准和构建方式，提高去中心应用(dApps)交易方式的交互能力。以太坊智能合约中执行的交易是对外公开的，免费使用，并且所有的dApp都可以接入其中。凡是构建在这套协议上的DApps都可以访问流动的公共池或者创建他们自己的流动池，并且根据数额收取手续费。这套协议是开放的：它不会将成本加在用户身上，也不会将其他价值从一组用户转移到另一组用户。去中心化的管理是持续集成的，并且安全地更新升级，不会影响到dApps和用户。
- 1 介绍
- 2 现状
- 3 说明书
- 3.1 消息格式
- 3.1.1 定点订单
- 3.1.2 广播订单
- 3.2 智能合约
- 3.2.1 签名认证
- 3.2.2 填单和局部填单
- 3.2.3 过期时间
- 3.2.4 取消订单
- 3.1 消息格式
- 4 协议代币
- 4.1 去中心化管理
- 4.1.1 持续集成
- 4.1.2 代币注册
- 4.1 去中心化管理
- 5 总结
- 6 感谢
- 7 附录
- 7.1 ERC20代币
- 7.2 合约 ABI
- 7.3 以太坊域名服务
区块链开启了一种变革，让所有人都可以通过一个开放的网络进行自由控制和转移资产，而不需要第三方的信息机构。如今有上百种区块链资产，并且每个月都在持续增加新的种类，各种资产形成了组合。随着智能合约的到来，在区块链上进行各种资产的相互交易成了可能，而且这也是一种不需要第三方信任机构的交易。
从中心化过渡到去中心化交易生态系统是一种非常重大的进步，以后有几点理由：去中心化可以提供十分健壮的安全保障，对于用户来说，将不会存在一个能够进行暗箱操作和会被政府监听的后台。Mt.Gox, Shapeshift, BitFinex的被黑证明了这种中心化交易所的危险。去中心化将会消除这种危险，让用户交易得放心，通过去除一个中间机构，去除单一的监管，实现所有人都成为监管人。
过去两年, 从以太坊诞生开始，各种去中心的应用已经建立了各种智能合约来实现点对点的交易。快速迭代以及缺乏最佳实践导致区块链上混乱繁杂。导致的结果就是，用户不得不去面对各种实现了同样功能的智能合约，但是这些智能合约都拥有各自的结构和学习曲线，代码质量和安全，这种状态强行增加了网络的不必要损耗， 将用户分割在各自的应用中，破化了价值在网络中的流动性。
0x 是一个用在以太坊上的开放的去中心化交易所协议。它将作为一个基础服务，可以和其他各种复杂的应用进行组合。0x 使用一个开放的可接入的智能合约系统，扮演一个基础设施的角色。像下面图1展示的那样。在长时间的运行中，一个开发的技术标准相对一个封闭的技术肯定会取胜。并且每个月都会有越来越多的资产成为链上的代币。我们将会看到越来越多的应用需要使用不同的代币。这就会促使一个开放的交易标准去支持这种开放的经济。
图1：开放的协议将是与应用无关的。将协议实现与应用实现之间进行解耦，如同开发者和使用者之间解耦一样。
由于以太坊智能合同实施的分散式交易，由于设计效率低下，对maker造成较高的摩擦成本，未能产生巨大的交易量。 特别地，这些实施将他们的订单放在块上，要求maker在每次发布，修改或取消订单时花费gas。虽然单一交易的成本很小，但是随着市场状况的变化，频繁修改订单也是非常昂贵的。除了市场做大的成本之外，维持一个订单上的订单将导致消耗网络带宽的交易，并且使块状膨胀而不必导致价值转移。
自动maker（AMM）智能合同被提出作为替代链订单的方式。AMM智能合同取代订单，采用价格调整模式，其中资产的现货价格对AMM市场交易的任何一方对市场力量和市场参与者都有决定性的响应，而不是彼此。AMM的优点包括可用性（始终可以作为交易对手，尽管其提供的现货价格可能比从更传统的交易所获得的现货价格更糟），并且易于与需要外部需要执行市场订单的智能合同集成。价格调整模型的确定性质量使其对市场流动性不敏感，这意味着交易导致价格在厚薄市场中移动相同的量。换句话说，AMM对供给曲线施加人为约束。如果价格调整模式过于敏感，即使是小型交易也会导致现货价格波动较大。如果价格调整模式不够敏感，AMM的资金将很快被套利者耗尽。
状态通道的意义在于缩小以太坊链的大小，并通过将交易移出块来降低各种应用（包括交换）的成本。状态通道的参与者来回传递加密签名的消息，累积中间状态更改，而不将其发布到正式链，直到通道关闭。状态通道是“条形码”应用程序的理想选择，其中许多中间状态改变可以在通过单个在线交易（即日交易，扑克，基于回合的游戏）结算之前在链外累积。如果其中一个通道参与者离开通道或尝试欺骗，则有一个挑战时期，在此期间，其他参与者可以发布他们从犯罪人那里收到的最新消息。因此，通道参与者必须始终在线，挑战不诚实的交易对手，因此参与者容易遭受DDOS攻击。虽然状态通道大大减少了特定用例的连锁交易数量，但开放和安全关闭状态通道所需的许多在线交易和安全存款使其对一次性交易无效。
一个混合型的实现，我们称之为“链外订单接收与链上结算”，将状态通道的效率与即时结算的链上订单相结合。在这种方法中，加密签名的订单从链外广播; 一个有兴趣的交易对手可以将一个或多个这些订单注入一个明智的合同，直接在块上无条件地执行交易。 摩擦成本最小化为市场制造者，因为它们可以在链外签名，交易只有在价值转移时才会发生。 我们扩展这种方法，允许任何人成为交易所，并使协议与应用无关。
图2显示了脱链relayer和链上处理的一般顺序。现在我们忽略了稍后会变得重要的几个机制。
图2：脱链relayer，链上处理图。灰色矩形和圆圈分别代表以太坊智能合同和帐户。指向以太坊智能合同的箭头表示函数调用; 箭头从呼叫者指向被叫方。智能合同可以在其他智能合同中调用功能。以太坊附带的箭头代表信息流。
- maker同意去中心交易（DEX）合约，以获取代币A的余额。
- maker创建代币A替换代币B的订单，指定所需的汇率，到期时间（超过该顺序无法填充），并使用其私钥对订单进行签名。
- maker通过任意渠道进行广播订单。
- taker接收到订单，并决定他们想填单。
- taker同意DEX合同访问代币B的余额。
- taker提交maker签名的订单到DEX合同。
- DEX合同认证maker的签名，验证订单尚未到期，验证订单尚未被填单，然后以指定汇率转让双方之间的代币。
每个订单是包含订单参数和关联签名的数据包。订单参数通过Keccak SHA3散列加密为32个字节。订单发起者使用其私钥对订单散列进行签名以产生ECDSA签名。
点对点订单允许双方使用他们更喜欢relayer直接互相交换代币。 构成订单的数据包是可以通过电子邮件，Facebook消息，耳语或任何类似服务发送的十进制数百字节。 订单只能由指定的taker地址填充，使得该订单对窃听者或外部用户无效。
表1 点对点订单的数据格式
| 名字 | 数据格式 | 描述 |
|---|---|---|
| version | address | 交易所智能合约的地址，当协议改变时，地址也会变 |
| maker | address | 生成订单的地址 |
| taker | address | 允许填单的地址 |
| tokenA | address | 代币的合约地址 |
| tokenB | address | 代币的合约地址 |
| valueA | uint256 | 代币A的总额 |
| valueB | uint256 | 相应A的代币B的额度 |
| expiration | uint256 | 失效时间(unix秒) |
| v | uint8 | v, r, s都是签名生成的参数 |
| r | bytes32 | |
| s | bytes32 |
对于流动性市场的出现，必须有一个公共场所，买方和卖方可以发布订单，随后汇总成订单表，即交易所。建立和经营交易所是昂贵的，迄今为止我们描述的协议并不能鼓励人们承担这种费用。广播订单通过允许任何人作为交易所，维护订单（公共或私人）并对所有流动性收取交易费用来解决这个问题。我们指的是托管和维护订单的relayers，而不是交易所。交易所必须建立和运营专有基础设施，执行交易并处理用户资金，而relayer仅通过托管和传播由通用消息组成的订单簿来交换市场参与者之间的代币。relayer不代表市场参与者执行交易，因为这将需要市场参与者信任relayer。相反，taker执行自己的交易。
广播订单的消息格式包括对点对点消息格式的两个更改，以促进公众交换和激励relayer。首先，广播订单不指定taker地址，允许广播的订单可以任何人拦截，任何人填写。第二，广播订单包括指定交易的费用A，费用B和费用接收者，以及由relayer用来收取交易费用的地址。交易所智能合同将这些费用转移到费用接收者，填写订单是否以及何时被填写。图3显示了maker和relayer用来协商交易费用的步骤顺序。
图3：relayer主持和维护一个链外订单，以换取交易费用。 该图显示了链外订单中，maker和relayer以无需信任的方式谈判交易费用的步骤顺序。 在交易结算后，交易费用从makerr和/或taker转移到relayer，扩充了图2所示的链上结算流程。
- relayer引用费用表及其用于收取交易费用的地址。
- maker创建一个订单，将feeA和feeB设置为满足relayer的费用表，设置值feeRecipient到relayer的接收地址，并用他们的私钥对订单进行签名。
- maker将签名的订单发送给relayer。
- relayer收到订单，检查订单是否有效以及提供的费用。 如果订单无效或不符合relayer的要求，则拒绝订单。 如果订单合格的话，relayer将订单交给订单簿。
- taker收到包含maker订单的订单簿的更新版本。
- taker将填好的maker的订单发送到以太坊链上的交易所的智能合约。
表2: 广播订单的消息格式
| 名字 | 数据格式 | 描述 |
|---|---|---|
| version | address | 交易所智能合约的地址，当协议改变时，地址也会变 |
| maker | address | 生成订单的地址 |
| tokenA | address | 代币的合约地址 |
| tokenB | address | 代币的合约地址 |
| valueA | uint256 | 代币A的总额 |
| valueB | uint256 | 相应A的代币B的额度 |
| expiration | uint256 | 失效时间(unix秒) |
| feeRecipient | address | relayer的地址 |
| feeA | uint256 | maker需要支付的协议代币 |
| feeB | uint256 | taker需要支付的协议代币 |
| v | uint8 | v, r, s都是签名生成的参数 |
| r | bytes32 | |
| s | bytes32 |
尽管maker指定交易费用似乎很奇怪，但请记住，relayer最终可以控制哪些订单被发布。因此，如果maker希望将订单发布到特定订单簿，则必须将feeA，feeB和feeRecipient设置为满足与该订单簿相关联的relayer的值。由于费用在非正式协商之外，relayer可能会动态更改收费表，并自行决定（对于尚未签署的订单，而不是现有订单）。relayer可以使用链上或链外的信息来设置和调整费用，允许灵活的费用表（固定费用，百分比，基于体积，分层，订阅模式等）。但是，一旦relayer接受了订单，订单的费用值就无法改变。
传统的交易所服务使用撮合引擎代表用户填单，用户必须相信交易所将为他们提供最优惠的价格。一般来说，用户可以放心，如果这些受管制实体试图作弊，或撮合引擎发生了故障，这些受管制实体将被追究责任。因为0x协议保持的无信任机制，relayer将不能代表maker和taker执行交易。相反，relayer只能向taker推荐最佳价格，taker自主决是否签署并将交易发送给区块链。这意味着0x协议不能支持真正的市场订单，但是，精心设计的Web应用程序可以接近这种类型的用户体验。
重要的是要认识到，feeRecipient可以指向任何智能合同。这意味着复杂的relayer结构可以“加入”0x协议。例如，可以根据每个节点在传播抗审查p2p网络中传播订单的贡献水平，在多个relayer之间分发交易费用或跨群体分发交易费用。
交易所协议是在可以公开访问和免费使用的以太坊智能合同中实施的（超出标准gas成本不会对用户造成额外费用）。 它以Solidity编程语言编写，包含两个相对简单的功能：填单和取消。 整个合同约为100行代码，并且大约需要90k的gas来填单。
交易所智能合同能够使用ecrecover函数来验证订单发起者的（maker's）签名，该函数将哈希和哈希签名作为参数，并返回产生签名的公钥。 如果ecrecover返回的公钥等于maker地址，则签名是真实的。
address publicKey = ecrecover( hash, signature( hash ) );
if ( publicKey != maker ) throw;
交易所智能合约存储对每个先前填单的引用，以防止单次订单被多次填充。 这些引用存储在映射中; 在这种情况下，数据结构将32字节的数据块映射到256位无符号整数。 将与订单相关联的参数传递到Keccak SHA3函数中会产生唯一的32字节散列，可以用于唯一标识该顺序（哈希冲突的几率，找到具有相同散列的两个不同阶数，几乎为零）。 每次填单时，映射将存储订单散列和填充的累积值。
在调用交易所智能合约的填充功能时，taker可以通过指定附加参数valueFill来部分填充订单。 只要部分填充的总和不超过订单的总值，可以在单个订单上执行多个部分填充。
表3: taker必须提供额外的参数当填单的时候
| 名字 | 数据格式 | 描述 |
|---|---|---|
| valueFill | uint256 | 总共需要填的tokenA的值 (valueFill <= valueA) |
订单的到期时间由maker在订单签署时指定。 到期时间是一个无符号整数值，表示自unix纪元以来的绝对秒数。 签名后无法更改此值。
以太坊虚拟机中的时间由块时间戳给出，每个时间戳在每次开始新的块时设置。 因此，订单的到期状态不取决于taker广播他们填单意图的时间，而是取决于矿工在EVM中执行填充功能的时间。 矿工不能将当前块的块时间戳设置为早于先前块的时间戳。
通过交易所智能合同的取消功能，关联的maker可能会取消未完成和未过期的订单。取消功能将订单的散列映射到订单的最大值（valueA），防止后续填充。取消订单需要花费gas，因此，取消功能仅用作回退机制。通常，maker预计将通过设置其订单到期时间来匹配他们打算更新其订单的频率来避免链上交易。
这种方法的一个问题是，它可以创建一个maker尝试在与taker试图填充同一个订单大致相同的时间取消其订单的情况。双方之间的交易将会失败，浪费gas，这取决于两个交易的开采顺序。有关开采交易序列的不确定性有时会导致不良后果。如果以太坊块链遭遇重大的待处理交易积压，这种不确定性可能会增加。
密码经济协议创造了财政激励措施，推动理性经济主体网络协调其行为，以完成一个过程。而0x基本上是一种网络协议，用于促进买方和卖方之间的代币（而不是一个加密经济协议），它旨在作为包含交换功能的dApps的开放标准。建立和维护开放标准是一个协调问题，为所有派遣方增加了运营开销;当各方有不同的需求和经济激励的时候，协调就会变得尤为棘手。协议代币可以协调财务奖励和抵消与围绕单一技术标准组织多方相关的成本。尽管调整采用激励措施是有用的，但协议代币可用于解决更具挑战性的问题：在不可变的智能合同系统中实现未来-分散协议。
一旦将以太坊智能合同部署到区块链上，其内部逻辑就无法改变。因此，为了更新协议，必须部署一个全新的智能合同，该协议要么网络分叉，要么干扰依赖该协议的用户和进程，直到他们“选择加入”最新版本为止。在交易所中，破坏性协议更新可能使所有未平仓的订单无效，并要求每个市场参与者批准新的智能合同来获取其交易余额。另外，该协议可以划分成并行运行的两个版本，中和由dApp互操作性创建的网络效应。虽然智能合同抽象可能被用于将更新不间断地集成到协议中而不会中断更高级别的进程，但是这种更新机制也可能为最终用户带来重大的安全风险（在最坏的情况下，攻击者可以获得用户资金的访问权限） ）。协议代币可用于驱动分散式更新机制，允许将更新统一到协议中，同时也保护协议的用户和利益相关者。
0x将被部署到具有固定供应的协议代币的以太坊块链，将被发布给合作伙伴dApps和将来的终端用户。协议代币将有两个用途：市场参与者向relayer支付交易费用，并对协议的更新进行权力下放治理。根据图4所示的过程，将使用分散化治理将更新安全地集成到0x协议中。最初，一个简单的多签名合同将用于分散式治理，直到开发更复杂的DAO。 0x协议及其本地令牌不会对用户施加不必要的成本，从relayer寻求租金或提取价值。协议的智能合同将被公开访问并完全免费使用。没有机制可以利用一个群体来牺牲另一个群体。
图4：可以部署协议更新，而不会通过合同抽象和分散式治理的组合中断网络。最终用户提供代理合同，可以访问他们计划交易的代币。 利益相关方提出并选择通过DAO在全新的智能合同（DEX v2）中实施的协议改进。 DAO授权新的智能合同访问用户代币，将其添加到代理合同的白名单中，最终取消列出不推荐使用的协议版本。
订单由机器可读的十六进制字节码组成，但这并不一定容易让人类视觉上解释。代币注册合同将用于存储每个代币的相关元数据的ERC20代币列表：名称，符号，合同地址和表示代币最小单位所需的小数位数（需要确定汇率）。注册管理机构将作为官方的在线参考，市场参与者可以在执行交易之前独立地验证代币地址和汇率。由于代币注册表将作为信任的信息来源，因此将需要监督从注册表添加，修改或删除代币。 0x利益相关者将提供这种监督。虽然代币注册表可以方便用户验证其订单的完整性，但是可以使用0x协议来交易使用ERC20代币接口的任何代币。
在将来，协议的订单格式可以被修改以便于人的可读性。代币可以通过在代币注册表中注册的三个字符符号来标识，而不是由代币的合同地址来标识。域名服务（ENS）可用于通过人为可读的名称（例如“theDunkle.eth”）来识别maker，taker和relayer，而不是通过帐户或合同地址。
- 链外订单relayer+链上结算=市场maker的低摩擦成本+快速结算。
- 任何dApp可以挂钩的公开访问的智能合同。
- 转账者可以创建自己的流动资金池并收取交易费用。
- 标准化+解耦=共享协议层→
- 提供dApps之间的互操作性
- 创造互惠互利的流动性网络效应
- 减少进入门槛，降低市场参与者的成本
- 消除冗余，提高用户体验和智能合同安全
- 分散式更新机制可使改进能够连续，安全地集成到协议中，而不会中断dApps或最终用户。
我们要感谢我们的导师，顾问和Ethereum社区的许多人非常欢迎和慷慨的知识。 特别是，我们要感谢Joey Krug，Linda Xie和Fred Ehrsam，对这项工作进行审查，编辑和提供反馈。 我们还要感谢我们在硅谷爱心会议上遇到的组织者和社区成员，包括Joseph Chow，Martin Koppelmann，Rebecca Migirov，Gustav Simonsson，Grant Hummer，Tom Ding和String Labs等人。
ERC20为代币组成的标记建立了标准合同ABI，并已成为所有类型数字资产的实际代表。 ERC20代币共享相同的合同接口，简化了与外部合同的集成。
核心ERC20功能包括：
- transfer（to, value）
- balanceOf（owner）
- approve（spender，value）
- allowance（owner，spender）
- transferFrom（from，to，value）
EIP101包括改变以太坊以遵循ERC20代币标准的建议。现在，可以使用“包装”智能合同作为ERC20以太网的代理。有关参考，请参阅Maker实现或Gnosis实现。
EIP50提出扩展合同ABI以支持结构。这将允许社区建立标准的订单和签名数据结构，简化我们的合同界面和与外部合同的集成。
将使用EIP137或Ethereum名称服务（ENS）将可读取的名称（例如“my- name.eth”）解析为可能代表Ethereum地址，Swarm和/或IPFS内容散列或其他标识符的机器可读标识符。 它也可以用于将元数据与名称相关联，例如合同ABI或whois信息。 ENS将被0x协议使用，以创建更直观的消息格式，可以根据名称选择引用maker，taker和relayer。
[1] coinmarketcap. https://coinmarketcap.com/all/views/all/. Accessed: 2017-02-016.
[2] Wikipedia: Mt. Gox. https://en.wikipedia.org/wiki/Mt.Gox. Accessed: 2017-02-016.
[3] A Timeline: ShapeShift Hacking Incident. https://info.shapeshift.io/blog/2016/04/19/timeline- shapeshift-hacking-incident. Accessed: 2017-02-016.
[4] Will Warren. The difference between App Coins and Protocol Tokens. https://medium.com/@willwarren89, 2017.
[5] Maker Market. https://mkr.market/. Accessed: 2017-02-01. [6] EtherOpt. https://etheropt.github.io/. Accessed: 2017-02-01.
[7] Augur. https://augur-dev.firebaseapp.com/. Accessed: 2017-02-01.
[8] Intrinsically Tradable Tokens. https://www.reddit.com/r/ethereum/... Accessed: 2017-02-01. [9] Euler. https://www.reddit.com/r/ethereum/... Accessed: 2017-02-01.
[10] Galia Benartzi Guy Benartzi, Eyal Hertzog. Bancor protocol: A hierarchical monetary system and the foundation of a global decentralized autonomous exchange. 2017.
[11] Abraham Othman, David M Pennock, Daniel M Reeves, and Tuomas Sandholm. A practical liquidity-sensitive automated market maker. ACM Transactions on Economics and Computation, 1(3):14, 2013.
[12] RaidEX. http://www.raidex.io/. Accessed: 2017-02-014.
[13] Jeff Coleman. State Channels. http://www.jeffcoleman.ca/state-channels/. Accessed: 2017-02-014. [14] Ledger Labs:State Channels Wiki. https://github.com/ledgerlabs/state-channels/wiki. Accessed:2017-02-014.
[15] IDEX, Decentralized Capital. http://www.idex.market/. Accessed: 2017-02-01. [16] EtherDelta. https://etherdelta.github.io/. Accessed: 2017-02-01.
[17] Fred Ehrsam. App Coins and the dawn of the Decentralized Business Model. https://blog.coinbase.com, 2016.
[18] Fred Ehrsam. How to Raise Money on a Blockchain with a Token. https://blog.gdax.com, 2016.