连载:Qtum量子链设计文档(二):基于UTXO的EVM集成方案以及合约存储和调用实现细节

量子链Qtum2018-06-04 19:51:31  阅读 -评论 0  阅读原文

连载:Qtum量子链设计文档(二):基于UTXO的EVM集成方案以及合约存储和调用实现细节点击上方蓝字关注QTUM公众号,了解最新行业资讯

连载:Qtum量子链设计文档(二):基于UTXO的EVM集成方案以及合约存储和调用实现细节

以下内容整理来自Qtum量子链吴明

Qtum原始设计文档汇总(2)-- Qtum区块链与EVM的集成

上一节中我们提到,Qtum底层采用与比特币一致的UTXO模型,在此之上建立了账户抽象层AAL,可以兼容多种账户模型的虚拟机。EVM作为当前最主流的智能合约虚拟机,是Qtum首先兼容的虚拟机。为了使EVM集成到Qtum区块链上,并正常工作,Qtum开发团队针对EVM和Qtum区块链的接口进行了大量设计和实现工作。 以下截取部分早期Qtum开发团队针对EVM的相关原始设计文档(附中文翻译)(ps:文档中QTUM或QTUMCORE为内部设计文档编号):

QTUM-3:Implement persistent storage for EVM Description:After this story is complete, EVM contracts should be capable of using persistent storage. These opcodes should work: SLOAD SSTORE When a block is orphaned or disconnected, the implementation must also ensure that the persistent storage is reverted to a state like the block was never received. Task:实现EVM的永久存储 描述:该任务完成后,EVM合约能够使用永久存储。操作码SLOAD和SSTORE可以工作。当一个区块成为孤块或者断开了,必须确保永久存储恢复到该区块没有被接受前的状态。

以上任务实现了EVM合约状态的存储,当合约再次被调用时可以获取正确的状态。并且在区块回滚时,合约状态可以恢复。

QTUM-4: Implement interface to blockchain from EVM Description: Contracts using the EVM should be capable of finding out certain things about the current state of the blockchain during their execution. The included opcodes for this story are the following: BLOCKHASH -- Get the hash of one of the 256 most recent complete blocks COINBASE -- Should return 0 for now (doesn't work with Bitcoin's model) DIFFICULTY -- Returns the difficulty of the previous block (not the current unmined block) TIMESTAMP -- Returns the timestamp of the last block NUMBER -- Return the last fully-mined block's nHeight GASLIMIT -- (don't worry about this, addressed in a later story), can be left as 1000000000 or similar for now Task: 实现EVM和区块链之间的接口 描述:使用EVM的合约在运行期间应该能够获取区块链当前状态的相关信息。为了实现该功能,需要以下的opcode: BLOCKHASH -- 获取最近256个区块中任意一个区块的哈希值 COINBASE -- 目前看来应该返回0(对Bitcoin模型无效) DIFFICULTY -- 返回前一个区块的difficulty(并非当前还未挖出的区块) TIMESTAMP -- 返回上一个区块的时间戳 NUMBER -- 返回上一个完全挖出的区块的nHeight GASLIMIT -- 目前可以为1000000000或类似的值

上述任务实现了Qtum区块链和EVM的接口,首次使得EVM可以和Qtum区块链进行交互。

QTUM-5: Implement calling other smart contracts from EVM Description: After this story is complete, EVM contracts should be capable of making calls into other contracts that are already on the blockchain. Includes these opcodes: CALL -- Message-call into an account CALLCODE -- message-call into this account with an alternative account's code (the alternative contract's code needs to be looked up from the utxo set. Suicide'd contracts should not be callable) DELEGATECALL -- Message-call into this account with an alternative account’s code, but persisting the current values for `sender` and `value` (should be very similar to CALLCODE) Also on callee side, these opcodes should function and return the appropriate values: CALLER ORIGIN CALLVALUE Task:实现EVM调用其他智能合约的功能 描述:该task完成后,EVM合约应该能够调用已经存在于区块链上的其他合约。涉及以下opcode: CALL -- message调用进入一个账户 CALLCODE -- message调用另一合约账户的代码(另一账户需要在UTXO集中查找,自毁合约不可调用) DELEGATECALL -- message-call调用另一合约账户的代码,同时保留当前`sender`和`value`的值(与CALLCODE非常相似) 在被调用侧,以下opcode应该运行并返回合适的值:CALLER、ORIGIN、CALLVALUE

智能合约的相互调用通过上述任务得以实现。具体规定了三种不同的调用方式。

QTUM-13: Allow EVM contracts to check their own balance Description: After this story is completed, a contract should be capable of checking it's own balance with the BALANCE EVM opcode. This balance should reflect the total amount of money assigned to the transaction using OP_EXEC_ASSIGN, including all relevant vouts in the current block. In accordance with the recent refinements to the accounting model, only certain OP_EXEC_ASSIGN transactions should be counted toward a contract's balance. The template for the script of these transactions follow: DEPTH 0NOTEQUAL NOT IF 0 ENDIF 1 (version) [gas limit] [gas price] (expressed in satoshis) [refund script bytecode] [data] [address] EXEC_ASSIGN IF [arbritrary code] (must be valid, such as IF opcodes must include ENDIF within this block) END Checking a contract's own balance should be fairly fast, and it is assumed an on-disk index or something similar will be needed to avoid full transaction index scans. The index should be based ont he given `[address]` field in the script. Important edge cases: When a contract is called using OP_EXEC_ASSIGN, it's balance at the time should include all transactions_before this transaction/vout_ in the candidate block. Example: Contract A has 1 qtum Transaction X received to give A 2 qtum. The Transaction is placed as tx number 5 in the block Transaction Y received to give A 3 qtum. The transaction is placed as tx number 8 in the block When the contract is executed as a part of X, it's balance will be 3 qtum. When the contract is later executed again as part of Y, it's balance will now be 6 (assuming during it's execution it didn't spend anything) If an OP_EXEC_ASSIGN transaction for some reason is removed from an in-progress block, all transactions that came after that transaction must be reevaluated Task:允许EVM合约检查自己的余额 描述:该任务完成后,一个合约将可以使用BALANCE EVM操作码来检查自己的余额。该余额应该能反映出使用OP_EXEC_ASSIGN分配给该交易的总金额,包括当前区块中所有相关的输出(vout)。 和记账系统最近的改进一致,只有特定的OP_EXEC_ASSIGN交易应该被计入合约的余额中。这些交易的脚本模板如下: DEPTH  0NOTEQUAL  NOT  IF  0  ENDIF  1 (version)  [gas limit]  [gas price] (expressed in satoshis)  [refund script bytecode]  [data]  [address]  EXEC_ASSIGN  IF  [任意代码] (必须是有效的,例如,在该区块内IF操作码必须包含ENDIF)  END  检查一个合约的余额应该足够快,我们设想它应该是一个在磁盘上的索引或者其他类似的可以避免对全部交易索引进行扫描的。该索引是基于上述脚本中给出的address字段的。 重要的边界情况:当一个合约通过OP_EXEC_ASSIGN被调用时,该合约那一刻的余额应该包含候选区块中所有在这个交易/vout之前的交易。例如:合约A有1个qtum,收到的交易X是给A发2个qtum。在区块中交易X为第5个交易。区块中第8个交易为交易Y,内容是给A发3个qtum。当该合约作为X的部分被执行时,它的余额将是3个qtum。当合约后面作为Y的部分再次被执行时,它的余额将会是6(假设在合约执行期间合约没有任何花费)。 假如一个OP_EXEC_ASSIGN交易由于某种原因从一个正在进行当中的区块中被删除了,那么在该交易之后的所有交易必须重新评估。

合约地址实际也是Qtum区块链上的合法地址,上述任务实现了合约对其余额的快速查询。

QTUM-14: Allow EVM contracts to check other contract's balances Description: After this story is complete, contracts should be able to check arbritrary EVM contract balances. Similar to #13, but for checking other contract's balances. This only covers deployed EVM contracts, and not regular bitcoin addresses. Edge cases: Also similar to #13, the balance of an account should include all transactions that have been processed in the current block, following transaction order. Example Contract A has 1qtum before this block Transaction X executes a contract which checks contract A's balance. Transaction Y assigns 2 qtum to contract A If Transaction X is placed before transaction Y in the block, the result should be 1 qtum. If Transaction Y comes first, then the result of the contract should be 3 qtum. Task:允许EVM合约检查其他合约的余额 描述:该任务完成后,合约能够查询任意的EVM合约余额。和QTUM13的任务类似,但是这里是检查其他合约的余额。当然,这仅仅覆盖了EVM的合约,不包括常规的bitcoin地址。 边界情况:和QTUM13类似,一个账户的余额应该包含当前区块中已经处理的所有交易,并且需要考虑交易顺序。 例如:合约A在该区块之前有1个qtum,交易X运行一个用来查询合约A的余额的合约。交易Y分配2个qtum给合约A。如果在区块中交易X被放置在交易Y之前,交易X的运行结果将会是1个qtum。如果是交易Y先发生,那么合约运行的结果将会是3个qtum。

与上一个任务类似,既然合约可以相互调用,那么获取其他合约的余额信息也成为了可能。

QTUM-25:Implement hard coded EVM opcode limit Description:For the purposes of the prototype, the maximum amount of EVM opcodes that can be executed in a single OP_EXEC or OP_EXEC_ASSIGN execution should be hardcoded to make DoS at least non-trivial. The limit should be very high enough to allow for very complex contracts, with it's intention being to prevent someone from just spamming infinite loop transactions and DoSing the network. Task:通过硬编码限制EVM操作码 描述:在第一版原型中,应通过硬编码的方式(即,写死的)设置单个OP_EXEC或OP_EXEC_ASSIGN可运行的EVM操作码上限。该限制可以设置地相对较高,从而可以允许比较复杂的合约操作,但是应控制在DoS攻击无法忽略的范围。设定这一限制的主要目的是防止出现无限循环的合约或其他DoS攻击。

为了限制DoS攻击发生的可能,需要对智能合约可运行的操作码总数作一定限制。另一方面,为了保证合约的多样性,支持较复杂的逻辑,该限制不能设置过低。上述任务通过硬编码的方式设定阈值,后续对此还会有陆续改进。

QTUM-55: Add separate EVM debug output file Description: We need to add a separate debug (vm.log) file for the EVM events, including any output from the EVM. That includes: - the quantumd Opened state DB. messages. - accounts outputs - Exceptions including outofgas and other VM exceptions as specified in QTUM-54 This will help use keep a clean history of the VM outputs. Task:添加单独的EVM调试输出文件 描述:我们需要针对EVM events,包括EVM的任何输出添加一个单独的调试文件(vm.log)。 它包括: •   Quantum开放状态数据库信息 •   账户输出 •   异常,包括在QTUM-54中提到的out of gas和其他的虚拟机异常 这将有助于对虚拟机的输出保持一个清晰的历史记录。

上述任务将EVM运行智能合约的调试信息以文件形式输出,可以实现部分智能合约调试功能。

QTUMCORE-45: Initialization of EVM environment (EnvInfo) Description: EVM environment is required to get information about blocks from Solidity. This information can be operated by the contract. Task:EVM环境的初始化(EnvInfo) 描述:EVM环境需要从Solidity中获取区块的信息。该信息可以被合约操作。 QTUMCORE-76: Create Qtum network gas params for the EVM Description: This was done in the DGP implementation, but since we are not launching the DGP in testnet-1, we need to implement our own network params as below: 1- create a new qtum genesis file: libethashseal/genesis/qtumMainNetwork.cpp the file should be based on: libethashseal/genesis/mainNetwork.cpp with below changes: First we change constants name: static dev::h256 const c_genesisStateRootQtumMainNetwork(""); // stateRootHash should be placed here after its computation static std::string const c_genesisInfoQtumMainNetwork = std::string() + then params section: {code:java}        "homsteadForkBlock": "0x0",        "daoHardforkBlock": "0xfffffffffffffff",        "EIP150ForkBlock": "0x0",        "EIP158ForkBlock": "0x0", {code} {code:java}        "registrar": "" {code} also in genesis section: {code:java} "extraData": "0x5174756d4d61696e4e6574c9987fd35877cdbbbb84ffeb5315ab1f86c21398c0", {code} We also need to update genesis block hashes and genesis rlp hash ... Task:为EVM创建Qtum网络gas参数 描述:这点已经在DGP的实现中完成了,但是由于我们在testnet-1中不发布DGP,因此我们需要实现如下网络参数: 1 -- 创建一个新的qtum创世文件:libethashseal/genesis/qtumMainNetwork.cpp 该文件应该基于: libethashseal/genesis/mainNetwork.cpp 且具有如下修改: 首先修改常量名称: static dev::h256 const c_genesisStateRootQtumMainNetwork(""); // 在计算static std::string const c_genesisInfoQtumMainNetwork = std::string() + 之后,这里的stateRootHash 应该被替换。 然后是参数部分: {code:java}        "homsteadForkBlock": "0x0",        "daoHardforkBlock": "0xfffffffffffffff",        "EIP150ForkBlock": "0x0",        "EIP158ForkBlock": "0x0", {code} {code:java}        "registrar": "" {code} 同样还有创世部分: {code:java} "extraData": "0x5174756d4d61696e4e6574c9987fd35877cdbbbb84ffeb5315ab1f86c21398c0", {code} 我们也需要更新创世块哈希和创世RLP哈希……

上述任务设定了Qtum区块链关于EVM的gas参数,主网和测试网络稍有区别。

QTUMCORE-101: Add and refactor new VM interface Description: In order to make the interface for VMs cleaner, and easier to use in the future, we should refactor how the EVM talks to the Qtum blockchain. We should implement a class like so that wraps the EVM and future VMs: class QtumVM (base class, and then there will be a QtumEVM class inherited from it) bool Initialize(QtumBlockchainInterface, VMTransactionInfo) bool Execute(ExecutionInfo info, VMVersion vmVersion, uint256 address, vector contractBytecode, uint64_t payment, ExecutionResult& results) class ExecutionInfo vector fullSenderScript – the full output script of the spent output from vin[0] uint256 senderAddress – lower 160 bits are typically address, upper bits are for flags to determine which address type, etc vector externalCallStack – stack of external calls (not used by EVM since it handles calls internally in a different way) uint8_t* [] inputData size_t [] inputDataLength uint64_t [] inputDataAddress – where to mount the data, ignored for EVM uint64_t gasLimit – gas limit for this contract execution uint64_t gasPrice uint64_t totalGasLimit – total gas limit for complete transaction execution bool allowPaymentConsumption – flag that indicates a contract/tx allows for it's payment to be consumed as gas (ignore for EVM) uint256 originAddress – address that sent the transaction that caused this execution (tx.origin in solidity) class ExecutionResult uint64_t gasConsumed uint32_t executionStatus uint8_t* outputData – don't make these vectors, because we want to ensure no data copies or allocations happen size_t outputDataLength map key, vector value>> storageWrites – Indicates every storage write that happened as a result of this execution (also includes storage writes in called contracts, not just current contract) uint64_t paymentConsumed – how much payment was consumed as gas cost (ignore for EVM) TransactionException EVMException – only for EVM compatibility class VMTransactionInfo int32 VoutNumber uint256 txid CTransaction fullTransaction bool Creation – true if current execution creates contract, otherwise false And then, we should also make a clean interface to the Qtum blockchain from the VM: class QtumBlockchainInterface uint256[] blockHashes – list of 256 block hashes (does not include current) vector ReadStorage(uint256 address, vector key) – leave this empty for now void WriteStorage(uint256 address, vector key, vector value) – leave this empty for now uint32_t[] blockDifficulties – list of 256 block difficulty (includes current) uint256[] blockCreators – list of 256 past block creators (includes current) uint64_t[] blockTimes – list of 256 past block times (includes current) uint32_t currentBlockNumber QtumVM.Execute should be called for all external contract calls excluding the EVM. For x86 contract calls, it will involve this function. For all key/values, they should be implemented as vector. However, for EVM versions of these functions, there should be an error if the length of the key/value is not 32 bytes. The EVM's access to database should remain as it is for right now. The EVM should be changed as little as possible. If one of the changes here involves extensive EVM changes, consult Earlz or Neil before going forward. Right now storage database interface can be ignored. This will be expanded later and made to function using a new database. Any error condition that occurs in this API (excluding QtumVM.Execute in the case of a contract fault) should throw a unique exception with info necessary for VMs to potentially handle the fault. For instance, in the x86 VM, ReadStorage might be used on a contract that doesn't exist. This should throw an exception, however the x86 VM will catch this exception, and tell the contract that an error occured. This work should be done on an unstable branch called qtum-x86 (with pull requests). It should still sync to the mainnet Qtum blockchain with no consensus changes after it is complete. Task:添加并重构新的虚拟机接口 描述:为了使虚拟机的接口更整洁,并且在将来更易于使用,我们应该重构EVM与Qtum区块链的交互方式。我们应该实现一个类来包装EVM和未来的VMs,比如QtumVM类(基类,且有一个继承它的QtumEVM类) •   bool Initialize(QtumBlockchainInterface, VMTransactionInfo) •   bool Execute(ExecutionInfo info, VMVersion vmVersion, uint256 address, vector contractBytecode, uint64_t payment, ExecutionResult& results) ExecutionInfo类 •   vector fullSenderScript – vin[0]的花费输出的全部输出脚本 •   uint256 senderAddress – 低160位一般是地址,高位是标志位,用于确定地址类型等等 •   vector externalCallStack – 外部调用的栈(EVM不使用,因为它以不同的方式在内部处理调用) •   uint8_t* [] inputData •   size_t [] inputDataLength •   uint64_t [] inputDataAddress – 在哪里装载数据,对于EVM则忽略 •   uint64_t gasLimit – 合约运行的gas limit •   uint64_t gasPrice •   uint64_t totalGasLimit –完整的交易运行的总gas limit •   bool allowPaymentConsumption – 标志(flag),指示合约/交易是否允许其付款可以用作gas消费(对于EVM则忽略) •  uint256 originAddress – 发送引起这次运行的交易的地址(在Solidity中是tx.origin) ExecutionResult类 •   uint64_t gasConsumed •   uint32_t executionStatus •   uint8_t* outputData – 不要把它们生成vectors,因为我们要确保数据不能复制或者分配 •   size_t outputDataLength •   map key, vector value>> storageWrites – 指示这次运行过程中所发生的每次存储器写入(不只是当前合约,也包括被调用的合约的存储器写入) •   uint64_t paymentConsumed –多少付款作为gas花费被消耗(对于EVM,忽略) •   TransactionException EVMException – 只用于EVM的兼容性 VMTransactionInfo类 •   int32 VoutNumber •   uint256 txid •   CTransaction fullTransaction •   bool Creation – 如果当前的运行创建了合约则为true,否则为false 然后,我们应该做一个VM到Qtum区块链的干净的接口: QtumBlockchainInterface类 •   uint256[] blockHashes – 256个区块哈希的列表(不包含当前的) •   vector ReadStorage(uint256 address, vector key) –这个暂时空着 •   void WriteStorage(uint256 address, vector key, vector value) – 这个暂时空着 •   uint32_t[] blockDifficulties – 256个区块难度列表(包括当前的) •   uint256[] blockCreators –过去的256个区块创建者列表(包括当前的) •   uint64_t[] blockTimes –过去的256个区块时间列表(包括当前的) •   uint32_t currentBlockNumber 所有的外部合约调用都应该调用QtumVM.Execute,除了EVM。对于x86合约调用,将包含该函数。 对于所有的键/值,它们应该实现为vector。 然而,对于这些函数的EVM版本,如果键/值的长度不是32字节,就应该报错。 EVM对数据库的访问应该保持原样。EVM的改动应尽可能地少。如果这里其中的一个改动涉及到大量的EVM修改,在继续之前请咨询Earlz或Neil。 存储数据库接口暂时可以忽略。这一点后面会进行扩展,并使用一个新的数据库完成该功能。 在这个API中发生的任何错误情况(不包括QtumVM,在合约出错的情况下运行)应该抛出一个独特的异常,其带有必要的信息让VM可能能够处理该错误。例如,在x86虚拟机中,ReadStorage可能被用在一个不存在的合约上。这将抛出一个异常,而x86虚拟机捕捉到该异常,并告诉合约出现了错误。 这个工作应该在一个不稳定的分支qtum-x86(带有pull请求)上完成。在完成后,它仍然应该与主网Qtum区块链同步且没有任何共识的改变。

在上述任务中,Qtum开发团队对EVM和Qtum区块链的接口进行了重构,使得EVM能够更好的集成到Qtum区块链上。

还有一些任务的具体实现和文档分布在Qtum的github仓库中,后续Qtum项目组会进一步整理,向社区公布。这些任务包括EVM的自毁操作码的实现,用于记录状态日志的EVM LOG操作码,用于合约与合约之间转账的实现等。

QTUM-10:EVM SUICIDE opcode support QTUM-11:Implement logging for EVM (LOG opcodes) QTUM-17:Allow EVM contracts to send other contracts money小结

本文主要还原了Qtum区块链与EVM集成相关的原始设计文档,解决了EVM集成,合约状态存储,合约调用等关键性问题,这些任务是在Qtum上运行EVM智能合约的重要基础。后续Qtum项目组会对关键文档作进一步解读。读者如果有任何疑问,可以在评论区中发表见解,或与Qtum项目组联系。

连载:Qtum量子链设计文档(二):基于UTXO的EVM集成方案以及合约存储和调用实现细节

关注Qtum量子链(qtumchain)公众号,回复关键字查阅Qtum量子链相关资料,以下是部分文档关键字

回复:‘白皮书’,查看《Qtum量子链白皮书,设计原理,实现方案,及应用》

回复:‘未来’,查看《Qtum量子链未来2年技术路线规划-简略版》

回复:‘指南’,查看《首篇Qtum量子链区块链开发指南系列面世》

回复:‘专访’,查看《Nasdaq专访Qtum:区块链会成为世界最大的信任服务商》

回复:‘文档’,查看英文版本《Qtum量子链实现文档》

回复:‘中文文档’,查看中文版本《Qtum量子链实现文档》

连载:Qtum量子链设计文档(二):基于UTXO的EVM集成方案以及合约存储和调用实现细节

连载:Qtum量子链设计文档(二):基于UTXO的EVM集成方案以及合约存储和调用实现细节

声明:链世界登载此文仅出于分享区块链知识,并不意味着赞同其观点或证实其描述。文章内容仅供参考,不构成投资建议。投资者据此操作,风险自担。此文如侵犯到您的合法权益,请联系我们kefu@lianshijie.com

参与讨论 (0 人参与讨论)

相关推荐

区块链存储方式——分布式数据存储 VS中心化存储

区块链存储方式——分布式数据存储 VS中心化存储

2019年的1024讲话,让区块链这个词焕然一新,以前它总是和传销和诈骗联系在一起,"区块链"这个词总是蒙上一层灰色。但是如今,区块链则是和实体经济融合紧密相连,成为国家的战略技术,这个词瞬间闪耀着热情的红色和生意盎然的绿色。区块链采用的分布式存储的方式。今天我们就来讲讲区块链的分布式存储和中心化存储的一些区别。中心化存储VS分布式存储在过去当中,一些中心化的数据库存储,数据量压力巨大导致网络堵塞

Project PAI 数据存储功能演示

Project PAI 数据存储功能演示

PAI-Data是一种文件存储服务,它使用PDP2协议规范对BitTorrent,IPFS和AWS等网络上的数据进行加密和存储,并已被用于PAIPass等多种PAI区块链上服务。在此处尝试PAI数据存储协议的演示:https://staging-paipass.p19dev.com/请按照以下步骤保存任意数据:● 点击链接:https://staging-paipass.p19dev.com/pa

Curve + zkSync L2:以太坊的ZK Rollup 智能合约

Curve 和 Matter Labs 团队很高兴宣布以安全且去中心化的方式向以太坊扩展迈出了一大步:今天,我们和 Curve Finance 一起发布了第一个常驻 dapp 的 zkSync L2 智能合约测试网。 为什么选择 ZK Rollup ? 扩展性是以太坊一个迫切的需求 - 隧道尽头有一个亮灯。Vitalik Buterin 刚刚宣布 Rollup 是现阶段扩展以太坊的“唯一选

中智院曹伟与中智科创谁在创造了谁?中智科创是做什么的?灵动IPFS分布式存储企业

中智院曹伟与中智科创谁在创造了谁?中智科创是做什么的?灵动IPFS分布式存储企业

2019年的深圳中智科创科技赋能APEC 展现深圳人工智能新名片与中智院曹伟有什么关系?灵动IPFS分布式存储企业应于任何企业 由工业和信息化部支持,深圳市的人民政府、工业和信息化部中小企业发展促进中心、中国中小企业国际合作协会、中国民营经济研究会共同主办的2019年在APEC中小企业工商论坛在深圳隆重开幕。中智院-曹伟-灵动分布式存储本次论坛以"创新创业创意发展,合作共赢共享未来"为主题,吸引了

​Web3.0中国峰会暨分布式存储生态大会到底密谋着什么?灵动IPFS分布式存储企业

​Web3.0中国峰会暨分布式存储生态大会到底密谋着什么?灵动IPFS分布式存储企业

在2020年11月12日,Web3.0中国峰会暨分布式存储在生态大会是深圳的会展中心的隆重展开开幕仪式,作为"2020中国国际高新技术成果交易会"重要组成部分,除活动的自带流量以外,同时共享着高交会来自智能科技、互联网、物联网、人工智能、大数据、新基建等行业在超40万名的专业观众,加强分布式存储在WEB 3.0中的技术应用、生态链、场景落地及广泛交流合作提供强有力的合作平台。灵动IPFS分布式云存

Bebt交易所:深入分析自动化做市商发展掣肘与设计改进

Bebt交易所:深入分析自动化做市商发展掣肘与设计改进

在基于区块链的分布式系统 (如 Ethereum) 上重构一个新的金融世界时,必须认识到区块链世界与链下世界相比,有着完全不同的动态属性。最值得注意的是,链上并非连续计时,而是通过区块来量化时间的流逝。但因为它受到区块大小的限制,这又导致了延迟问题和计算能力的限制。由于这些结构上的差异,分布式金融的设计者应该具有与中心化世界的设计者完全不同的思路。例如,由于区块链的成本和技术基础设施,做市商在基于

比特币有什么缺点?

1.交易平台的脆弱性。比特币网络很健壮,但比特币交易平台很脆弱。交易平台通常是一个网站,而网站会遭到黑客攻击,或者遭到主管部门的关闭。2.交易确认时间长。比特币钱包初次安装时,会消耗大量时间下载历史交易数据块。而比特币交易时,为了确认数据准确性,会消耗一些时间,与p2p网络进行交互,得到全网确认后,交易才算完成。3.价格波动极大。由于大量炒家介入,导致比特币兑换现金的价格如过山车一般起伏。使得比

业务中使用区块链的四种方式

业务中使用区块链的四种方式

暴走时评:区块链是一种支持像比特币这样的数字货币的公共分类帐本,并且正改变着我们的业务方式。一旦那些对匿名交易,甚至是秘密交易感兴趣的人接纳了这样一种鲜为人知的工具,加密货币就会日趋成为主流。 区块链是一种支持像比特币这样的数字货币的公共分类帐本,并且正改变着我们的业务方式。一旦那些对匿名交易,甚至是秘密交易感兴趣的人接纳了这样一种鲜为人知的工具,加密货币就会日趋成为主流。越来越多的个人和企

麦妖榜
更新日期 2019-09-03
排名用户贡献值
1牛市来了30910
2BitettFan24187
3等待的宿命23810
4区块大康20369
5六叶树20310
6linjm122719429
7天下无双16192
8lizhen00215280
9让时间淡忘14586
10yelanyi050511349
返回顶部 ↑