魔笛手Q&A | 王琦: 预言机问题——区块链应用落地的阿喀琉斯之踵
Claire:
@王琦 谢谢分享！非常精彩！👍👍看看大家有什么问题，可以一起讨论。
焦木:
@王琦 相當於只對信息進行共識的區塊鏈吧，工作組內部怎麼實現信息驗證呢？
王琦:
我们不做链，链下只是一个P2P网络，并没有记录状态，主要是要在这个网络里面实现共识。
焦木:
如果每個節點抓取的時間不一樣，信息可能就不一樣，這個就會驗證失敗吧。
王琦:
整个过程很快，大概在1秒钟左右，大部分API的变化没有那么敏感，可以覆盖绝大多数情况。
焦木:
是希望用短時間內無變動來規避問題了，明白了。只做共識，不做帳本。
王琦:
绝大多数API变化都没那么快，对于变化敏感的数据，没有办法做链下聚合，只能做链上聚合，这样性能会退化。未来，如果这样的数据需求很多，我们会把聚合方式做成plugable的，在失败几次之后，转为链上聚合。
焦木:
每種信息的oracle都有自己的密鑰對？如果有一天需要audit，如何判斷信息是否來自你們呢？
王琦:
我们不对信息分类。我们只是data channel， 用户需要访问什么信息对我们来说是透明的。
焦木:
我覺得你們最好有個log，帳本式不重要。這樣在出現連帶責任時可以自證清白。
王琦:
每一个工作组有一个组公钥，组内每一个节点有他们自己的私钥碎片，这些信息都是链上可查的。
因为我们链上有管理合约，所有的request都会经过管理合约，相当于保存了metadata。可以用来时候audit.
焦木:
你是說，請求Oracle服務時產生動態密鑰對？
王琦:
不是服务时产生的。而是在分组的时候就产生好组公钥，和每个节点的私钥碎片。服务的时候每个节点用自己的私钥碎片，对信息签出一个签名碎片来。
焦木:
我舉一種情況，我一個菠菜類應用，聲稱調用了你們的服務，然後操縱了一個數據，這種情況下你們有法在事後自證清白嗎？
王琦:
查看请求历史就可以。我们会把组签名连同数据结果发到链上。并在我们的合约里经过验证。只要查看区块历史，就能看到我们究竟发回来得是什么数据。
焦木:
這個歷史由你們的合約寫在鏈上？
王琦:
节点在返回数据的时候，会先调到我们的合约里，链上就会有记录。在我们的合约里验证通过以后，再调用当初用户提供的callback function.
焦木:
那如果別人冒充你們的網絡，跟你們的鏈上合約交互呢？
王琦:
那他是过不了验证的，因为会有一个链上验证的步骤。
焦木:
用什麼機制呢？如果都是開源的，他們可以模仿你們的機制啊！
王琦:
只有组内超过一定阈值的节点得到相同的结果，才能拼出有效的签名来，才可以通过验证。但是他们不会有这个组的各个节点的私钥碎片，这个是别人很难控制的。
焦木:
好！謝謝分享！回頭看過你們白皮書後再交流。
王琦:
嗯嗯，欢迎多多交流！感谢大家，如果有进一步的问题，可以私聊我，或者加入我们社群进行更深入的交流。
焦木:
小公司正常，大公司就會被人盯上。
Claire:
@王琦 好的👌今天非常感谢你在百忙之中花时间和我们分享！💐💐
王琦:
谢谢大家~
Claire:
大家有问题可以在社区随时留言，我会汇总给王琦先生释疑！再次感谢王琦先生的精彩分享！
周训波:
@王琦 感谢分享！客户链是把取得的预言结果发给DOS network节点进行验证？还是把预言链的数据取下来进行验证？还是其他？
王琦:
并没有链~是DOS Network的工作组内的节点去互联网API去取结果，取到之后在工作组内做共识，签出一个有效的结果来，再把结果返回给主链。
周训波:
就是返回的结果包括预言，还包括所有节点产生的数据与签名？
王琦:
"周训波: 就是返回的结果包括预言，还包括所有节点产生的数据与签名？"
包括选中的节点组共识过后产生的数据，以及对这个结果的证明。
周训波:
@王琦 谢谢！期待看到你们的白皮书和开发文档。
盼盼:
特别赞👍
王琦:
好的，都在我们的官网上，https://dos.network
焦木:
@周训波 我自己總結是：收到請求後，各選中節點背對背拿到要預言的數據，一致時分享私鑰片段，私鑰完整後對數據簽名後連同數據發回消費鏈。
王琦:
这里有个小问题，不是一致时分享私钥片段。而是无论如何都会分享签名片段，然后当收集的片段满足条件时，即拿到的相同数据大于阈值时，可以拼出完整签名，然后返回主链。
焦木:
2/3？是比例？另外，用vrf結果來跟閾值比較時，符合條件的節點數會波動很大，節點數越少這個偏差越大，這塊你們怎麼處理的？@王琦
王琦:
是1/2，确切地说是（x+1）/ 2，x是组内总节点数。具体论证在白皮书里，太大太小都不好，组内节点数是固定的。
焦木:
好
王琦:
vrf得到随机数，选出工作组，组是事先形成好的。
焦木:
明白，那其實要求節點保證liveness吧？另外一個就是節點實際是permissioned.
王琦:
需要保证liveness，但实际上只要大部分节点liveness就行了，不需要每一个都live. 是permissionless的，任何人都可以加入，只要抵押一定量代币就可以了。
周训波:
能否这么理解:
消费者(任一节点)发起一次预言(相当于票据)。根据这个票据可以获得一个确定性的结果，过半的节点投票签名认可结果的真实性。
DOS节点无许可门槛，如果有作弊，会损失抵押的代币。
焦木:
一個工作組多大規模？押金多少？總發行量多少？
Stomer Wong:
有点BANCOR协议的味道。
王琦:
"周训波: 能否这么理解:
消费者(任一节点)发起一次预言(相当于票据)。根据这个票据可以获得一个确定性的结果，过半的节点投票签名认可结果的真实性。
DOS节点无许可门槛，如果有作弊，会损失抵押的代币。"
不准确，确切的说应该是，
- 主链上的Dapp需要访问某一数据，他需要给出要访问的数据源的API，比如www.google.com/nba/, 调用DOS在主链上的接口合约。
- DOS在主链上的合约把请求通过异步通知（在以太上市event log）的形式传递给链下节点。
- 哪些链下节点需要工作，是由vrf生成的随机数选取的。
- 这些节点分别去之前的数据源API抓取数据，并对之签名，把签名碎片广播。
- 如果超过半数节点拿到的结果是一样的，则可以把这些签名碎片拼成一个有效签名。
- 然后把这个签名，连同数据返回主链的DOS合约。
- 在DOS合约里用工作组的公钥验证签名是否正确。
- 通过验证以后，调用由Dapp提供的callback function，并且把数据结果传递过去
王琦:
"焦木: 一個工作組多大規模？押金多少？總發行量多少？"
我们在这里实现了一些优化，工作组大小暂定21个，押金一个节点需要50K个token。总发行1B token.
焦木:
@王琦 vrf的話，女巫攻擊怎麼處理的？
王琦:
所以要抵押token才能加入网络，增加门槛，让fake identity成本增加。
"焦木: 一個工作組多大規模？押金多少？總發行量多少？"
我们在这里实现了一些优化，工作组大小暂定21个，押金一个节点需要50K个token。总发行1B token
焦木:
50k相對於1B很小啊。
周训波:
@王琦 你这么描述比较清晰了。👍👍
主链上发起请求的dapp节点是多个，还有事后验证预言内容时的请求，可能不是一次或一波。会不会有不一致的可能？
焦木:
10^9/10^3/50 = 2 * 10^4，可以分兩萬份，這個50k你們有論證嗎？
周训波:
DOS.network的faq描述有点少。建议结合case补充点具体的(合约)例子。
Claire:
@焦木 @周训波@Stomer Wong @王琦 谢谢各位大神的观点和问题！高水平的交流！小白们获益良多！👍👍😄😄
王琦:
@周训波 不会，因为只有大部分节点一致的情况下才能拼成有效签名，才会往链上发。
王琦:
"周训波: DOS.network的faq描述有点少。建议结合case补充点具体的(合约)例子"
有的，您需要看我们的技术文档，有具体的合约例子，在官网上也有。
王琦:
"焦木: 50k相對於1B很小啊"
这是一个节点的量，我们expect有几千个节点，所以单个节点的量也不能太多。同时还能保证有一定门槛。
Jimmy 「世界需要愛」创始人 MTI:
@王琦 請問現在有什麼dapp在上面運行嗎？可以學習下？
王琦:
如果有进一步的问题，可以联系@孙孝虎@DOS Network ，欢迎来我们社区提问。我们目前还在测试网，还没有上主网。
我们不是公链，不能运行dapp，而是dapp需要调我们的接口，用我们的service. 具体用例可以参考开发文档，在官网上有入口。
感谢大家的关注和支持！我们也出了一个产品，1月份的tron开发者大赛，我们基于我们的测试网，在tron上做了一个差价合约金融衍生品平台。
感兴趣可以了解一下。其中，计算最终出发条件的那一环，用了我们自己的oracle 服务。
（全文完）
