0x是基础的创建区块，可以作为Dapps的共享基础设施，长远看，它是开源的技术标准，比封闭架构更有优势。
在0x的白皮书上提到，自动做市商的智能合约是链上订单簿的替代性方案。它采用价格调整的模式。它的好处是容易对外部智能合约进行整合。价格调整模式让它们对市场流动性非常敏感，自动做市商对供给曲线施加了人为约束。如果价格调整模型太敏感，小额交易也会产生大的现价波动。如果价格调整模型不敏感，自动做市商资金将很快被套利者消耗。
另外，状态通道被看作是
以太坊区块链扩张的一种方式，还可减少不同应用的费用。状态通道中的参与者来回传递加密签名信息，可累积中间状态的变化，与此同时无须把它们发布到规范链，许多中间状态改变可以链下累计，直到链上完成结算。状态参与者必须实时在线，以挑战不诚实的参与方，因此对于DDOS攻击很脆弱。
为了解决这个问题，0x提出的解决方案是：链下订单中继，链上最终结算。它结合了状态通道效率和链上订单簿的快速结算。加密签名的订单在链下广播，这些订单送进链上智能合约以去信任化方式执行。这样，对于做市商（maker发起方）来说，交易摩擦成本低。
1）链下订单中继和链上结算的基本步骤
Maker 批准后，去中心化交易所的智能合约获取账户要交易代币（假设为A）的余额
Maker 创建一个订单，要用代币A交换目标代币（假设为B），确定具体的汇率、截止时间等，并用私钥加密签名订单
Maker可在任何媒体广播订单（twitter、邮件、博客、
论坛等）
Taker 获取订单并决定接受订单
Taker 同意后，去中心化交易所的智能合约获取代币B的余额
Taker 提交Maker签名的订单到去中心化交易所合约
去中心化交易所合约认证Maker的签名，确认订单没有过期，确认订单没有被交易，之后按确定汇率进行代币交换。
每个订单是一个数据包，包括订单参数和加密签名。订单参数通过Keccak SHA3功能链接并散列为32字节。maker用私钥签名订单哈希以产生ECDSA签名
订单数据包数百字节大小，可以通过邮件、社交网络、即时通讯等任何媒介发送。订单只接收特定的taker的地址，窃听者或外部第三方都无法接收。
2）订单的广播
买卖双方要交易，需要有一个流动性的市场，可以进行订单发布，以形成订单簿。对于大多数项目团队来说，创建和运营交易所需要耗费巨大资金。而0x协议可以让项目团队以较小成本维持交易所，并自定义交易费用。托管和维护订单簿的主体都是一个中继者。普通的中心化交易所创建和运营基础设施，需要管理交易和处理用户资金。而中继者只需通过托管和传播订单簿来推动市场交易。这个过程中，中继者并不代表交易者执行交易，Taker必须自己执行交易。
广播订单的信息格式也相对灵活。一是广播订单并不要求taker地址，允许订单被任何人接收；二是订单的费用值等参数都可以设置。中继者托管和维持一个链下的订单簿，当交易清算后，交易费从maker或taker（也可能两者都需要）转到中继者。其中：
中继者创建费用计划和设置用于收取交易费用的地址
maker创建订单，设置fee A（代币）和fee B（代币）的值，这些值满足relayer的费用计划，设置fee接收人的地址，并用私钥签署订单
maker把签名订单转移到relayer
relayer接到订单，检查订单有效性及要求费用。如果订单无效，或不满足relayer要求，订单会被拒绝。如果满足条件，relayer把它发布到订单簿
taker接收到订单簿，其中包括maker的订单簿
taker接受maker的订单，并提交到交易所的智能合约
这里面，虽然maker设置交易费用，但最终来说relayer控制进入订单簿的订单，因此，这里有一个平衡，maker想要把订单发布到订单簿，就需要满足relayer。Relayer也可以设置费用计划，可以是固定费用、按比例收取、按交易量收取或分层收取等模型。但，一单relayer接收了订单，进入了订单簿，就不能改变。
传统的交易服务是由交易所设定机制来进行买卖双方的匹配，交易双方必须相信交易所能提供最好的价格。而在0x，所有的交易都是去中心化的，也就是说relayer不能像传统的交易所那样代表maker和taker进行交易，relayer智能推荐，最终由taker决定签名和发送交易到区块链上。
3）智能合约
交易所协议是在以太坊智能合约上执行，开放且免费使用，不会向用户收取除gas费用之外的任何费用（执行智能合约的必须费用）。它用solidity语言编写，包括两个相对简单的功能：成交和取消。整个合约大概100行代码，大概需要花费90k gas来成交订单。
4）签名确认
交易所智能合约能够认证发起人使用ecrecover函数的签名，它将哈希和签名哈希作为参数，并返回产生签名的公钥。如果ecrecover返回的公钥等于发起人的地址，该签名是真实的。
Addresspublickey=ecrecover(hash,signature(hash));If(publickey!=maker)throw;
5）成交和部分成交
交易所智能合约存储之前每个成交的记录，防止单个订单多次成交。这个参考记录存储进一个映射，数据结构可以映射一个32字节数据到256位未签名整数。传递与一个订单相连的参数到keccak SHA3函数可以产生唯一的32字节哈希，它可以用于唯一确认的订单（哈希冲突的可能性，发现两个不同订单拥有一个哈希，现实上不可能），每次一个订单成交，影射存储订单哈希并积累成交值。
当调用交易所智能合约成交功能时，一个taker通过制定附加参数实现部分成交。只要部分成交的总额没超过总订单额度，多方部分成交就可能在单个订单上执行。当试图成交订单时，Takers必须提供额外的参数。
6）截止时间
一个订单的截止时间由maker指定，截止时间是一个未签名的整数值，它代表从unix纪元绝对秒数。签名后值就不能改变。以太坊虚拟机的时间是由区块时间戳来给定的，当一个新的区块被挖出来之后，时间就出来了。因此，一个订单的截止时间状态并不依赖于一个taker广播它们的成交意图，它依赖于一个矿工在EVM上执行交易后的时间状态。
7）取消交易
一个没有成交或到期的订单可以由相关的maker通过交易所智能合约的取消功能进行取消。取消功能映射一个订单的哈希，对应着订单的最大值（valueA），防止后续交易。取消订单花费gas。该方法可能有一个尴尬情况：一个maker试图取消交易，与此同时，一个taker试图接收该订单。考虑到交易挖矿的序列有不确定性，会导致意料之外的结果。如果以太坊区块链有大量的积压订单待处理，不确定性就会增加。
8）ZRX代币
跟其他代币一样，0x的ZRX代币也是为了驱动形成代理网络，它想通过协议成为开源标准，协调所有参与方，通过激励促使大规模采用代币，在一个没有中心治理下实现自运行的网络。
0x的代币主要用于支付relayer的交易服务费，另外就是0x协议升级时的去中心化治理用。根据ZRX代币的拥有量，在协议升级等方面拥有相应的影响力。
9）去中心化的治理
一旦一个以太坊智能合约部署到区块链，它的内部逻辑不能改变。因此，升级协议必须部署一个完全新的智能合约，要么对网络分叉，要么升级用户和处理流程，直到选择最新版本。交易场景下，协议升级可以让所有公开订单无效，并要求每个市场参与者批准新的智能合约来获取它们的交易余额。或者，协议分叉成为两个版本运营。尽管智能合约可以持续地集成升级到协议中，同时不会中断更高级的进程，这样的升级机制可能给终端用户带来极大的安全隐患。（最坏情况是，攻击者可以获得用户资金的访问权限。）
协议代币可用于驱动去中心化的升级机制，允许把升级持续地集成到协议中，与此同时也能保护协议用户和持有人。
一开始，一个简单的多方签名合约将用于去中心化的治理，最后会有一个复杂的DAO产生。0x协议和它原生代币将不会对用户强加非必要的费用，或者从relayer那里抽取费用。
股份持有人提出和选出协议改善计划，通过DAO用完全新的智能合约执行。DAO批准新的智能合约以获取用户的代币，获取的方式是增加它们到代理协议的白名单，并且最终不上不推荐的协议版本。
10）代币注册
订单由十六进制字节码组成，机器可读，不适合普通用户阅读。代币注册合约将用于存储ERC20代币的列表，每个代币都有相关的元数据：名称、符号、合约地址、表示代币的最小单元所需的小数（需要确定汇率）。注册将用于官方的链上参考，可以被是参与者使用，在执行交易前用来独立确认代币地址和交易汇率。代币注册将用作可信的信息资源，监管是必须的，包括从注册处增加、修改或移除代币。0x股份持有人将提供监管。
未来协议的订单格式可修改，便于用户阅读。代币在代币注册处显示为3个字母而不是代币合约地址。以太坊域名服务（ENS）可用于确认maker、taker、relayer，这些都是要变成用户可读的名称，比如“theDunkle.eth”,而不是账户或合约地址。
结语
总的来说，0x是基于以太坊区块链的p2p的ERC20代币交易所协议。它有标准的开源协议、通用的创建区块，在分布式应用中实现交易功能的互操作性。基于0x协议的去中心化应用可以进入公开的流动池，或创建自己的流动池，并在收取一定的手续费。根据白皮书，主要特点如下：
链下订单中继+链上结算=市场maker（发起者）低摩擦成本+快速结算
开放可获取的智能合约，让任何Dapp都能使用
中继者可以创建它们自己的流动池，并根据交易量收取交易费
标准化+解耦=共享协议层
提供dapps间的互操作性
创造流动性的网络效应，这让大家受益
降低进入门槛，降低市场参与者的成本
消除冗余，提高用户体验和智能合约安全
去中心化的升级机制，允许升级改善可以持续而安全地集成到协议中，并且不会打扰dapps或用户。
总之，0x协议试图把信息传输从应用层转入协议层，从而实现dApp间的互操作性。但0x也有其弱点，比如taker必须在线匹配明确订单，撮合实时性较差，另外OTC方式暂时无法显示复杂订单撮合。
常用链接
官网：https://www.0xproject.com/#home
白皮书：https://www.0xproject.com/pdfs/0x_white_paper.pdf
版权申明：本内容来自于互联网，属第三方汇集推荐平台。本文的版权归原作者所有，文章言论不代表链门户的观点，链门户不承担任何法律责任。如有侵权请联系QQ：3341927519进行反馈。
