使用GearSV为比特币引入智能合约

 
当比特币来自比特币时，比特币开发者和社区成员已经成为最具建设性的一类。后者，包括像霓虹灯Planaria，Bitbus库和承销商这样的个人，为挖掘节点提供了一种新的有趣方式，可以轻松地与离线应用程序状态同步。
这要归功于这种解决方案，比特币可以根据相对高度对块进行排序，还可以对任何交易进行内部块索引。这意味着什么是非常值得注意的，磁带本身就是构建所需要的所有东西，不仅是更复杂的应用程序，而且是比特币完全图灵完备的应用程序。
Planaria安全模型
首先，更高的一致性和可用性 –
使用此应用程序代码的任何和所有服务器都可以在任何时间段内有效地死亡，并且仍然能够通过从最后看到的块中抓取来恢复相同级别的有效性。这意味着应用程序提供商可以轻松关闭并重新联机，几乎没有一致性风险。虽然这是一种有效的解决方案，但它是唯一可用的，取决于向用户提供此类应用程序的相关经济激励。
第二 – 改进验证 –
比特币生态系统中的任何用户都能够启动应用程序服务器并验证其及其当前状态。这对于验证器的工作原理是它首先从应用程序的代码中获取应用程序的代码，然后从查看应用程序的第一个块开始直到当前块高度。
这就是我们通常所说的线性时间验证系统，它类似于比特币核心网络上的挖掘节点。唯一的区别是它只在区块链状态下只有一个应用程序子集发生。
最后，法律 –
如果有任何API提供商试图通过提供虚假合同状态以任何方式进行欺骗，那么抓住并将其保持在正确的帐户中将变得更具挑战性;特别是考虑到试图在法庭上提供任何实质性证据所带来的挑战。
最终，通过这种升级，由于它现在都源于链上的磁带，所以他们完全没有办法通过简单的“烹饪书籍”来摆脱它。
内存插件和CPU
目前使用Planaria的一些应用程序是比特币的有效扩展，旨在提供更大的硬盘空间和支持。其中一些包括Twetch和Bicomedia。除此之外，这些类型的应用程序还能够从Op_return事件中抓取和提供文件系统上的静态内容。
总的来说，GearSV的基本目标是提供更多无限量的CPU空间和内存，可以轻松添加到比特币中。这让比特币完全做到了什么?想象一下，如果你有办法提供更复杂的任意数据操作，并提供更具挑战性的验证，所有这些都具有与存储应用相同的底层属性，但更高层次?这就是它所提供的。
虚拟机
因此，作为虚拟机的一些简要背景 – 它们作为底层区块链硬件的一层运行。这允许系统计算层与更广泛的CPU架构一起有效运行 – VM越好，它可以运行的架构范围越好。
虚拟机对于用户需要更长时间和更多种机器所需的智能合约特别有用。事实上，我们所知道的ARM服务可能会在未来几年内因其有效性而流行起来。
通过使用Web Assembly Virtual Machine，用户可以将C ++和Rust等代码编译成附属的字节码。然后，您可以为这些底层方法生成专用的ABI和Javascript接口。对于那些使用以太坊更舒服的人来说，这似乎很熟悉。
关于合同
通过使用此解决方案 – 开发人员可以创建有效的基于类的程序，这些程序通常可以从Solidity中看到。这是一步一步如何做到的。
首先 – 编译您的合同以生成字节码和ABI
您可以通过使用Emscripten之类的东西有效地搭载Web装配工具，以便自动编译和生成用于C ++合同编码的Javascript接口。这是一种类似的解决方案，也可用于Rust代码。
第二 – 将联系人Bytecode部署到一个链上Op_return
与具有智能合约解决方案的其他平台非常相似 – 然后用户通过在op_return输出中存储关联的Bytecde on-chain来“部署”此合约。合同标识符是如何确定的。
第二 – 将联系人Bytecode部署到一个链上Op_return
与具有智能合约解决方案的其他平台非常相似 – 然后用户通过在op_return输出中存储关联的Bytecde on-chain来“部署”此合约。合同标识符是如何确定的。事务哈希是通过使用b：//协议。
OP_RETURN
19HxigV4QyBv3tHpQVcUEQyq1pzZVdoAut
[wasm_bytecode]
WASM
二进制
Token.cpp
现在，写作
任何和所有写入最终都在链事务上，它们使用更高级别的语义来指定契约方法，并将每个参数输入到op_return中。 Planaria及其节点所做的是抓取事件日志并按顺序运行所需的方法调用，因为它们会在链上发生。
OP_RETURN
[deploy_transaction_hash]
[method_id]
[params_array]
JSON
UTF-8
它的可扩展性
然后，这些开发人员可以轻松使用通过各种云平台提供的商用硬件或虚拟CPU，以便开始使用它。
当使用基于WASM的智能合约时，限制因素来自它所具有的内存类型。对于使用更像C ++ std :: map的令牌契约，其相关的34字节地址将转换为32字节的无符号整数，实际上在具有16 GB内存的机器上将发生超过2亿的余额;造成非常可能的瓶颈。
那么我们怎样才能超越这种内存限制呢?合同创建者可以使用Web Assembly MemFS，将其安装到其下面的操作系统中。通过这样做，您可以利用其关联的硬盘驱动器。
与以太网等平台形成鲜明对比，以太网是智能合约在一台虚拟机中运行和运行的平台。比特币的新智能合约以更加“分片化”的方式运作;一台虚拟机正在运行并运行一个智能合约。
这要归功于这种解决方案，开发人员最终可以为每个合同运行无限数量的虚拟机，以便显着提高(不仅仅是最终用户的可用性)，还可以通过内置的可扩展性确保相互易用性。
所以，在结论中
这个解决方案最终意味着，您不仅可以在比特币上编写和部署智能合约。但这样可以实现更具可扩展性，通用性和高效性的方法。
正如我们从其他开发人员那里看到的那样 – 这类契约的最常见和最常见的用例是令牌。具有严格且严格的op_return框架(例如Tokenized提供的框架)为开发人员提供了太多不灵活的解决方案 – 限制了与令牌无关的用例。
提供更高程度的程序灵活性意味着开发人员可以实际指定具有诸如归属计划，荷兰拍卖机制，支票审批等功能的复杂合同。