Solidity

The thinking of project about FISCO BCOS

此篇博文以笔者参与的项目为背景进行编写,内容包括但不限于联盟链( FISCO-BCOS )在对该项目的业务与其技术实现中发挥的作用。在本文中笔者会多次引用到与业务或FISCO-BCOS的相关名词,若有疑问可查看本文引用的文章链接进行查看。以下内容为个人看法及观点,可能出现因考虑不足或经验缺乏导致的错误,若读者朋友发现任何问题及有任何疑问,还请不吝指教,我们共同探讨与进步,谢谢。 FISCO-BCOS能解决的实际问题 如何发挥区块链的优势,在链上编写自己的业务逻辑 使用SDK,让业务系统与区块链进行交互 在此项目前笔者更多的会关注公链,具体来说就是Ethereum,也着手写过一些Solidity智能合约,了解一些底层的技术实现。对联盟链的认知与“玩法”也只停留在听过像Fabric,R3等项目名词而已。那么通过这次机会熟悉了另一联盟链——FISCO-BCOS,关于其更多介绍可在文章引用链接部分查看。 项目面临的问题和其解决之道 首先简单介绍项目(下面简称项目A),以便为下文做铺垫。项目A主要解决在无第三方机构储存个人明文资料的情况下,对这些个人资料做验证,保证其真实性以及没有被篡改。 众所周知,在中国大陆有许多类似学信网这样的网站由政府持有,作为储存个人资料和提供查询服务的第三方服务机构,这样的第三方服务机构储存了大量个人信息资料的网站。在笔者所参与的项目,其落地的区域隐私保护条例相对严格,在一些情况下,连政府机构也不允许随意流转与储存个人资料,那如何解决资料接收方查实资料真伪的问题呢? FISCO-BCOS提供了这样的一个解决方案,在资料的拥有方与资料的查证方之间搭建起一个区块链网络,各方拥有各自的区块链节点,链上存储资料credential。资料的拥有方通过节点发布资料credential,资料查证方通过节点使用链下接收到的明文资料向区块链查询真伪,比对credential后即可知道查证方收到的资料是否与资料拥有方拥有的资料一致。 在这个过程中,不存在有三方机构对资料的明文进行存储,也能确保资料的真实性。下面笔者针对项目A所涉及的业务,结合 FISCO-BCOS 提供的开源方案(1.提供链底层;2.提供一套智能合约作为链上的业务逻辑控制)进行分析与介绍。 在这里要注意的是,在链下传输证书明文时需注意安全问题,针对该项目的安全实施方式在此我就不详细展开,读者可以根据自己业务流程建立相应的安全机制。 链上的业务逻辑——智能合约 本文是以区块链应用层面展开描述,至于FISCO-BCOS提供的区块链底层支持细节,可以在参考资料[1]FISCO-BCOS查看。 笔者会以大笔篇幅来详述这一章节,以笔者角度来解析相关代码。这一套智能合约设计流程和相关描述可查看参考资料[2]。在阅读本章节前还应了解链上各机构扮演的角色及其作用参考资料[3]。 笔者会结合这些资料与读者一同解析代码,如果有错误的地方,欢迎在评论区提出。另, 读者在阅读此章节若具备智能合约相关知识,阅读起来会相对轻松。 FISCO-BCOS 与Ethereum的智能合约都使用Solidity编写,由于Solidity也是由于Ethereum才出现在大众的视野里,所以本文多处会提到Ethereum。 请忽略图1列表中的红色下划波浪线,笔者先从权限控制功能的智能合约开始,再解析业务相关的智能合约部分。 权限控制部分 RoleController.sol 笔者从RoleController.sol开始解析,该合约保存了WeID相应的角色,并可从各角色中移除、添加WeID。下文如未特指某WeID表示为个人,WeID均默认表示为链上机构。...

Continue reading...

Difference new() with depoly() of Solidity for Smart Contract

今天在做基于Ethereum的古董投资Dapp(编写完成后笔者会开源)单元测试时发觉了一个问题的存在,如题。我不确定new一个合约后返回的实例(一串十六进制的HASH)是否与deploy返回的HASH一样也是一个合约地址,在社区询问后无果,就自己在remix里写了一小段代码验证我的想法。希望能帮助读者解决这方面的困惑。 需要注意的是笔者在remix里的Environment是Injected Web3,使用MetaMask里的Kovan Test Network去完成测试。测试的Token可以在这里领取:https://gitter.im/kovan-testnet/faucet在gitter里发送你的钱包地址即可。下面进入正题: 图1 图1是我编写的一端简易的测试代码。我通过图右边的deploy直接将合约B部署上测试网络,在图左边的合约B代码中读者可以看见new了合约A的实例,那么我的猜想是否正确呢?我们将在测试网络的Ethereum区块链浏览器上看出结果。 图2 如图2,图左最上方的那条Transaction是我直接deploy后返回的结果(点进链接可查看详细内容,下面会详解)。图左下面三条是我new(点击图右下aInstance函数,详细代码看图1)实例后的结果。 图3 图3是点进deploy返回结果的链接显示的页面,图3下面的input Date是合约B的十六进制字节码,如图3所示创建红框里的合约并且返回其合约地址。对比图4、5、6,图4、5、6是new实例的详情。 图4 图5 图6 对比图3、4、5、6可以看出Transaction的对象(红框里的地址)都是同一串HASH,唯一不同的是图3是创建该合约,而其余三张是通过此合约再去创建另一合约(也就是创建新的合约地址)。所以图3没有图4、5、6最上面选项卡Internal Transaction。 图7 图8 图9 点进选项卡Internal Transaction,图7、8、9是new实例对象通过B合约创建的三个新的合约,图7、8、9红框中显示的是三个不同的合约地址。笔者点击图9红框中合约地址可见下图10的该合约的详情。 图10 图11 图10红框中的十六进制字节码与图11中合约A的字节码相同,点击进入图7、8的合约地址看到的字节码与图10、11的字节码也是相同的。即合约B每一次new都为创建合约A创建了新的合约地址,所以图1中Instance就是新的合约地址。与deploy效果一样返回的也是一个合约地址。 若笔者文中存在错误之处,欢迎各位读者指正,共同学习。

Continue reading...