小明学习笔记 | 一文看懂区块链跨链机制_AIN:BTour Chain

跨链是什么?

第一种是有一组同时承担两条链节点的个人或联盟,也有可能是一条单独的链,告诉B链A链上发生什么事,或者告诉B某个消息的真的。比如Ripple开发的跨账本价值传输开放协议Interledger,但它不是链,只是一套网关协议。V神把这种称为公证人模式。Inanotarymechanism,atrustedentityorsetofentitiesthatistrustedasagroupisusedinordertoclaimtochainXthatagiveneventonchainYtookplace,orthataparticularclaimaboutchainYistrue.Suchentitiesmaybeactive,listeningandautomaticallyactingbasedoneventsinsomechain,orreactive,issuingsignedmessagesonlywhenasked.ThemostadvancedeffortthathastakenstepsinthisdirectionistheInterledgerprojectdevelopedbyRipple.Interledger,atleastinwhatitdescribesas“atomicmode”,usesaByzantine-fault-tolerantconsensusalgorithminordertoachieveconsensusamongasetofnotariesonwhetherornotagiveneventtookplace,andthenissuesasignaturethatcanbeusedtofinalizepaymentsconditionalonthisconsensus.另一种则是侧链/中继,与公证人模式的“别人告诉B链A链上发生的事”不同,中继模式则是更“直接”地B链自己读A链。比如通过验证A链区块头和默克尔树等信息验证A链上的交易,比如以太坊上的BTCRelay。根据公开资料,BTCRelay的运作机制如此:“一个外部的第三方,被称为Relayer,发送一个交易到BTCRelay的智能合约,内容是最新的比特币区的区块头。BTCRelay基于现存的区块头信息校验发送的区块头的有效性。如果校验通过,则加入到BTCRelay维护的比特币区块头链。”由此,在BTCRelay的智能合约里,实现了一个内置的SPV节点,可以用来校验比特币交易的有效性。在以太坊平台的任意用户或者是智能合约都能请求BTCRelay来验证,是否某个在比特币网络上存在某个交易。但这种一方面只能实现单向锚定,一方面需要以太网络中有Relayer不断往合约中提交验证信息,赚取用户手续费。其实这个模式逻辑上更困扰我的地方在于,既然侧链也需要第三方的Relayer提交信息,Relayer的角色跟“公证人”很类似,不同之处只在于侧链打包了主链的区块头。Relaysareamore“direct”methodforfacilitatinginteroperability,whereinsteadofrelyingontrustedintermediariestoprovideinformationaboutonechaintoanother,thechainseffectivelytakeonthetaskofdoingthatthemselves.Thegeneralapproachisasfollows.SupposethatasmartcontractexecutingonchainBwantstolearnthateitheraparticulareventtookplaceonchainA,orthatsomeparticularobjectinthestateofchainAcontainedsomevalueatsomeparticulartime.SupposealsothatchainAisdesignedsimilarlytoBitcoinorEthereuminthatithasanotionof“blocks”and“blockheaders”,wherea“blockheader”isacompactpieceofinformationthat“represents”theblock(andpossiblystatedata)insomecryptographicallyauthenticatedway,mostlikelyusingMerkletrees.V神认为,利用轻客户端验证技术SPV确实可行,能验证区块头及其之默克尔树中对应的交易。Thisuseofthisso-called“lightclientverification”technologyisidealforrelaysbecauseofhowfundamentallyresourceconstrainedablockchainis.Infact,itisimpossibleforamechanisminsidechainAtofullyvalidatechainBandamechanisminsidechainBtofullyvalidatechainAatthesametime,forthesamesimplemathematicalreasonwhytwoboxescannotsimultaneouslycontaineachother:Awouldneedtore-runthepartofBthatre-runsA,includingthepartofAthatre-runsB,andsoforth.Withlightclientverification,however,aprotocolwherechainAcontainssmallpiecesofchainBandchainBcontainssmallpiecesofchainAthatarepulledon-demandisentirelyfeasible.AsmartcontractonarelayonchainBthatwantstoverifyaparticulartransaction,eventorstateinformationonchainAwould,muchlikeatraditionallightclient,verifyabranchofthecryptographichashtreeofchainA,thenverifytheblockheaderthattherootofthisbranchisinside,andifbothcheckspassitwouldacceptthatthetransaction,eventorstateinformationiscorrect(notethatbecauseblockchainsarefullyselfcontainedenvironmentsandhavenonaturalaccesstotheoutsideworld,therelevantbitsofchainAwouldneedtobefedintochainBbyauser;however,becausethedataisinacryptographicsense"selfverifying",thisuserthatfeedsthisinformationinneednotbetrusted).首先,怎么验证交易,说到这里可能要简单Mark一下什么是SPV,网络上有不少科普文,其中iBlockKim这个作者写得比较清楚:根据中本聪在比特币白皮书里描述:“不运行全节点也可以验证支付,用户只需要保存所有的区块头就可以了。用户虽然不能自己验证交易,但如果能够从区块链的某处找到相符的交易,他就可以知道网络已经认可了这笔交易,而且得到了网络的多个确认。”一个区块链中的信息通过两两打包,最后归纳成一个节点,即根节点,区块头中包含了根节点的哈希值,包含了所有交易又大大减少了区块头部的大小。不仅如此,当要搜索某一个交易,比如上图中的23的时候,可通过几步,比如0-2-5-11即可以快速搜到。因此,SPV在寻找交易时,只需下载寻找区块头而不是整个区块。区块头只有80字节,每小时6个,一年也就4M大小。那么如何定位区块呢?比特币提供了一种叫做布隆过滤器的功能,节点会在通信链路上建立一个这样的过滤器,限制只接受含有目标地址的交易,从而能过滤掉大量不相关的数据,减少客户端不必要的下载量。比如,SPV节点会收到少于1KB的有关区块头和Merkle路径的数据,其数据量只约占一个完整区块的千分之一。然后怎么打包,用BTC举例的话,侧链协议实际的操作步骤是:提交锁定交易:比特币持有者在BTC主链上发送一个特殊交易,把比特币锁定在BTC链上。等待确认:在BTC链上等待锁定交易被更多区块确认,以防止该锁定是虚假的交易。解锁交易:锁定交易确认后,用户在侧链上创建一个解锁交易花掉锁定交易的输出,并提供SPV工作量证明,并将赎回交易的输出导入自己在侧链上的地址中。等待一个竞争期:竞争期也被称作可修改阶段,作用是防双花。而且在此期间,解锁交易不会被打包到区块新转移到侧链上的比特币还不能被使用如果解锁交易包括了比特币主链更大难度的SPV证明,则上一个解锁交易将被替换。竞争期结束后,该解锁交易将被打包到区块中,用户可以使用他的比特币了。跟BTCRelay类似,中继模式的弊端在于成本太大,V神也认为验证对方链上的信息会影响速度。可以想象,如果你单纯用“公证人模式”,只需要等比特币链上确认就行了,可是如果验证信息还要上侧链,就意味等待确认的事情多了很多。阿希链并没有选择打包区块链,就是因为单青峰认为,将区块头打包上链“成本比较大,没有通用性,解决了比特币的解决不了以太坊的”。同样万维链也没有用,吕旭军表示,Voucher共识的模式还在验证阶段:工程上Voucher信息的提交和验证如果上链,需要耗费较高的链上资源并限制吞吐量;经济上需要更合理的激励机制让Voucher成员积极参与并消极作恶。较为知名的跨链项目还有Cosmos和Polkadot,不过都未落地。在Cosmos中,不同空间通过IBC协议分别和“中心”通信,不同空间的信息包裹经过中心传输。为了保证传输无误,一个证明需要被发布在接收方的区块链上。接收方为了验证这个证明,需要时刻了解发送方的区块头,类似侧链采用的机制。Polkadot中继链的区块包含平行链的区块头,还有一些确认信息,以避免双花。验证人负责运营中继链节点,并验证平行链上的区块;可能还会有一个收集人运行特定平行链的全节点,负责提交新区块。万维链暂时使用的方式,是哈希锁定,也叫原子互换,主要是通过哈希时间锁和密数让双方完成交易,不需要第三方公证人。这个方式通俗来说可以这样理解:假设小明要转10个ETH给小红,小红要转10个wan给小明;小明在以太坊一智能合约里锁了10个ETH加上一个密码的哈希值,并置入条件:如果小红在10小时内提供了密码,合约验证之后小红就能获得10个ETH,否则回滚;小红在万维链一智能合约里锁了100个wan并把密码的哈希值放在里面,并置入条件如果小明在5小时内提供了密码,就能获得100个wan;小明看到小红在wan也锁了钱,就凭密码到wan上拿走了100wan;小红也从wan上的合约中得知密码,凭密码到ETH合约中拿走10个ETH。我们可以把小红换成万维链的Storeman,用户只需要在发起交易、释放密数、撤销交易的环节进行操作。对于参与跨链的Storeman,万维链会提供专门的客户端,客户端根据协议进行无需值守的自动化运行。这是一个比较成熟的方案,闪电网络用的也是这个,安全度高不过似乎应用场景比较少。如果是单纯两个用户交换资产,其实哈希锁定是个挺安全的方式,而且只靠哈希锁定就能完成。这跟上面两种不太一样,哈希锁定还能可以跟第一种结合使用,万维链目前就是这么做;闪电网络就是哈希锁定+多签。关于这三个不同技术的应用场景可以看看V神的总结。另外一个涉及到跨链的技术叫做多重签名技术,有的项目也会采用分布式私钥。比如闪电网络中就利用了多重签名,交易双方需要对同一个交易签名,交易才可以被确认。跨链的很多模式,都会涉及到一个作为“连接器”的网关,跨链网关主要负责读取各自公链上的账户信息,共同对某账户下待跨链的数字资产锁定与解锁。为了安全,这个网关往往是一个多节点共同维护的中继网络和多签名账户。有一定比例的节点参与了之后,才算完成签名。阿希链用的是多重签名技术。万维链中用的安全多方计算+门限秘钥的技术,Storeman必须共同参与计算才能生成锁定账号的公私钥,而私钥只是理论存在,从未出现在网络中,而是以碎片的方式分散在各Storeman手中,交易时参与方要再次合力才能共同构造签名,且互不泄露碎片。为了保证可用性,只需要一定比例的Storeman参与计算即可构造签名。PS.有小朋友看了文章之后觉得锚定币生成跟EOS主网映射有点混淆,关于这点我请教了一下MEET.ONE,他们表示,EOS映射是类似做快照,主网上线之后可以使用映射生成的私钥登录,在新主网上取回资产。大概是,Block.one开发了一个映射的以太坊智能合约。用户如果要映射的话,需要使用EOS的工具生成一个秘钥对,再调用合约上面映射的方法。以太坊的公钥地址跟EOS的公钥地址一一对应,对应关系存在了以太坊上,EOS主网启动团队把这些快照下载下来之后,在主网启动之后按快照发放代币。小明学习笔记链接:第一期:《小明学习笔记|一文看懂区块链虚拟机》我是Odaily星球日报编辑卢晓明,探索真实区块链,爆料、交流请加微信lohiuming,烦请备注姓名、单位、职务和事由。参考文章:Vitalik给R3提供的跨链技术报告下载:ChainInteroperabilityV神:区块链跨链技术大规模应用将在一到两年内爆发主流跨链技术深度解析解读区块链-跨链技术深入理解跨链技术区块链的互操作性:CosmosvsPolkadot对话比特币侧链RSK:扩容且加入智能合约后的BTC能成为金融基础设施吗?跨链梳理之侧链及OneLedger简评BTCRelay项目解决区块链跨链问题的中继方案瑞波提出的跨链技术InterledgerProtocal(ILP)详解Polkadot白皮书Cosmos白皮书区块链学习基础篇—简单支付验证SPV

郑重声明: 本文版权归原作者所有, 转载文章仅为传播更多信息之目的, 如作者信息标记有误, 请第一时间联系我们修改或删除, 多谢。

金宝趣谈

[0:0ms0-5:663ms