硬核解读 Hydro Protocol 智能合约 1.1 版本更新
2018年12月，我们发布了Hydro Protocol 智能合约。同时，DDEX 开始采用Hydro合约：
https://github.com/HydroProtocol/protocol
3个月的时间，Hydro 合约结算的交易数据包括：
60000+ 交易次数，每天 700+ 交易次数
2500万+ 美金交易量
125+ 种交易代币
在与用户、做市商、DeFi合作伙伴的沟通中，我们发现了新的需求以及V1.0版本中不尽合理的设计。为了更好地支持Hydro Relayer（Hydro 节点交易所）生态，扩大DeFi的力量，我们更新了部分合约逻辑，推出V1.1版本。
我们将在3月27日更新Hydro合约v1.1版本。
以下是Hydro合约v1.1版本的更新内容及解读：
更新做市商返点参数
v1.0：
做市商交易时缴纳makerFee，Hydro合约再将makerFee和rebate（返点）统一转入做市商账户。
这一设计的初衷是使参数足够灵活，但与做市商的接触中我们发现绝大多数情况下做市商会要求免除makerFee，并按比例分得takerFee。所以我们修改了参数形式。
v1.1：
做市商地址全部免除makerFee，并把takerFee按比例返点给做市商。
将buyer字段添加到Match事件
v1.0：
Match log 没有显式声明buyer和seller。
v1.1：
在Match事件中添加buyer字段，在log中可以轻易区分buyer和seller。
从EIP712中移除「verifyingContract」和「version」字段
v1.0：
EIP712是一项以太坊优化提案。去中心化交易所中的order是一串二进制信息，EIP712使得用户可以看到解析后的order信息，大大方便了用户阅读。
在升级合约时，EIP712中的verifyingContract和version字段对Relayer造成了困难，Relayer必须取消所有的用户挂单。
因为domain是order id的组成部分，如果我们升级了合约，就意味着所有的order id都要更新，Relayer不得不抛弃用户所有已经挂出的订单。
另一方面，这两个字段并没有包含用户的挂单信息，反而要求用户有相关知识才能理解。简单来讲，在实践中，它给交易用户带来的困惑多于安全感。
v1.1：
移除了EIP712的verifyingContract和version字段，做到Relayer对合约升级无感知。
注：这并没有牺牲任何安全性。用户可以在任何时刻验证Hydro proxy的白名单，并可以在链上取消自己的挂单。
为matchOrders添加baseTokenFilledAmounts参数
v1.0：
matchOrders功能：在原有的设计中，Relayer的撮合引擎提供给合约一系列maker订单和一个taker订单，合约可以自动计算撮合数量。这要求撮合引擎正确模拟链上撮合结果，并严格按撮合顺序发送交易。
v1.0 match Orders function
v1.1：
为了降低开发撮合引擎的难度，我们决定添加baseTokenFilledAmounts参数，将撮合结果作为参数传入matchOrders函数。
另外，在以太坊上，交易顺序由上链顺序保证。但是其他链却不都是这样的设计。通过这个参数，也能够减少对交易顺序的依赖，为Hydro合约应用于多条公链，作准备。
v1.1 baseTokenFilledAmounts 参数
添加isMakerOnly字段
通过与API用户沟通(尤其是做市商)，一个常见的请求是添加一个字段，以确保他们所下的订单永远不会成为taker订单。
因此，我们在订单数据结构中添加了一个新的“isMakerOnly”字段，在合约层面保证该订单不会成为taker。
2018年，我们聚焦于为去中心化交易所建设基础架构，迭代了多个DDEX版本，设计了Hydro智能合约。构建了一套目前以太坊上最先进的撮合引擎+结算合约。
2019年，我们基于去年的成功积累，部署多链交易所，积极推动Hydro Protocol与DeFi项目合作，助力开放式金融生态。
接下来 Hydro 将陆续发布一系列新的消息，敬请期待哦！
Hydro Protocol Team
【近期动态】
【近期行研】