时间:2024-03-15|浏览:254
用戶喜愛的交易所
已有账号登陆后会弹出下载
Original author: Mirror Tang | Salus; Yixin Ren | Hongshan capital; Lingzhi Shi | Salus; Jiangyue Wang | Salus
Original source: panews
In the past year, as generative AI has repeatedly exceeded public expectations, the wave of AI productivity revolution has swept through the cryptocurrency circle. We have seen that many AI concept projects have brought about a wave of wealth creation myths in the secondary market. At the same time, more and more developers have begun to develop their own "AI+Crypto" projects.
However, a closer look reveals that the homogeneity of these projects is very serious, and most of the projects only focus on improving "production relations", such as organizing computing power through decentralized networks, or creating "decentralized Hugging Face” etc. Very few projects attempt true integration and innovation from the underlying technology. We believe that the reason for this phenomenon is that there is a "domain bias" between the AI and blockchain fields. Despite their extensive intersection, few people have a deep understanding of both fields. For example, it is difficult for AI developers to understand the technical implementation and historical infrastructure status of Ethereum, and it is even more difficult to propose in-depth optimization solutions.
Take machine learning (ML), the most basic branch of AI, as an example. It is a technology that allows machines to make decisions based on data without explicit programming instructions. Machine learning has shown great potential in data analysis and pattern recognition, and has become commonplace in web2. However, due to the limitations of the times when it was first born, even at the forefront of blockchain technology innovation such as Ethereum, its architecture, network and governance mechanisms have not yet used machine learning as an effective tool to solve complex problems.
"Great innovations are often born in cross-fields." Our original intention in writing this article is to allow AI developers to better understand the blockchain world, and also to provide new ideas for developers in the Ethereum community. In the article, we first introduced the technical implementation of Ethereum, and then proposed a solution to apply machine learning, a basic AI algorithm, to the Ethereum network to improve its security, efficiency, and scalability. We hope to use this case as a starting point to present some perspectives that are different from those on the market and inspire more innovative cross-combinations of “AI+Blockchain” in the developer ecosystem.
Ethereum’s technical implementation
Basic data structure
The essence of a blockchain is a chain connecting blocks. The key to distinguishing chains is the chain configuration, which is also an indispensable part of the creation of a blockchain. For Ethereum, chain configuration is used to distinguish different chains in Ethereum and identify some important upgrade protocols and flag events. For example, DAOForkBlock marks the height of the hard fork at which Ethereum experienced a DAO attack, and ConstantinopleBlock marks the block height at which Constantinople was upgraded. For larger upgrades that include many improvement proposals, special fields will be set to identify the corresponding block height. In addition, Ethereum includes various test networks and main networks, and the corresponding network ecology is uniquely identified through ChainID.
The genesis block is the zeroth block of the entire blockchain, and other blocks directly or indirectly reference the genesis block. Therefore, the correct genesis block information must be loaded when the node is started and must not be modified arbitrarily. The configuration information of the genesis block includes the aforementioned chain configuration, and also adds fields such as relevant mining rewards, timestamps, difficulty, and gas limits. It should be noted that the consensus mechanism of Ethereum has evolved from proof-of-work mining. The mechanism is converted to proof of stake.
Ethereum accounts are divided into external accounts and contract accounts. The external account is uniquely controlled by a private key, while the contract account has no private key control and can only be operated by calling the contract from the external account to execute the contract code. They all contain a unique address. The Ethereum world state is an Ethereum account tree. Each account corresponds to a leaf node, which stores the status of the account (various account information and code information).
Transaction: As a decentralized platform, Ethereum’s essence is for transactions and contracts. Ethereum’s blocks are packaged transactions, as well as additional relevant information. The specific blocks are divided into two parts, namely the block header and the area. Block, in which the block header data contains evidence that connects all blocks into a chain, which we can understand as the previous block hash, as well as the state root, transaction root, receipt root, and proof of the state of the entire Ethereum world. Several other indicators indicate difficulty, counting nonce and other additional data. The block body stores the transaction list and the list of uncle block headers (since Ethereum has converted to proof of stake, the uncle block reference no longer exists).
Transaction receipts provide the results and additional information after the transaction was executed that cannot be obtained directly by simply looking at the transaction itself. Specifically, the information contained in it can be divided into: consensus content, transaction information and block information, including information on whether transaction processing is successful and consumption information such as transaction logs and gas. Debug smart contract code and optimize gas consumption by analyzing the information in the receipt. and provides a form of confirmation that the transaction has been processed by the network, and the results and impact of the transaction can be viewed.
In Ethereum, gas fees can be simply understood as handling fees. When you send Token, execute a contract, transfer Ethereum, or perform various operations on this block, the operations in these transactions require gas fees. Ether When processing this transaction, the computer needs to perform calculations and consume network resources, so you have to pay gas fees to let the computer work for you. The final fuel fee is paid to the miners as a handling fee. The calculation formula for the specific fee can be understood as Fee = Gas Used * Gas Price, which is the actual consumption multiplied by the consumption unit price. The unit price is set by the initiator of the transaction, and its amount is often determined. Determines the speed of transactions on the chain. If the setting is too low, the transaction may not be executed. At the same time, it is also necessary to set a gas limit consumption upper limit to avoid errors in the contract causing unpredictable gas consumption.
trading pool
In Ethereum, there are a large number of transactions. Compared with the centralized system, the number of transactions per second processed by the decentralized system is obviously bleak. Due to the large number of transactions entering the node, the node needs to maintain a transaction pool to properly manage these transactions. The broadcast of transactions is carried out through p2p. Specifically, a node will broadcast an executable transaction to its neighboring nodes, and then the neighboring nodes will broadcast the transaction to the neighboring nodes of the node. In this way, A transaction can spread to the entire Ethereum network within 6 seconds.
Transactions in the transaction pool are divided into executable transactions and non-executable transactions. Executable transactions have a higher priority and will be executed and packaged in the block, while all transactions that have just entered the transaction pool are non-executable transactions. It will then become executable. Executable transactions and non-executable transactions are recorded in the pending container and the queue container respectively.
In addition, the transaction pool will also maintain a local transaction list. Local transactions have many advantages. They have higher priority, are not affected by transaction volume restrictions, and can be reloaded into the transaction pool immediately when the node is restarted. The local persistent storage of local transactions is implemented through journal (reloading when restarting the node). Its purpose is not to lose unfinished local transactions and will be updated regularly.
The legality of the transaction will be checked before entering the queue, including various types of checks, such as: anti-DOS attack, anti-negative transaction, transaction gas limit, etc. The simple composition of the transaction pool can be divided into: queue+pending (the two constitute all transactions). After completing the legality test, subsequent checks will be carried out, including checking whether the transaction queue has reached the upper limit, and then judging remote transactions (remote transactions are non-local transactions) ) is the lowest in the trading pool, replace the lowest price transaction in the trading pool. For the replacement of executable transactions, by default only transactions that increase the handling fee by 10% are allowed to replace transactions that are already waiting for execution, and will be stored