Due to the English description of solidity, it is a little different every time I read it, and I understand more. For example:
1. Blockchain and transactions
A blockchain is a globally shared, transactional database. This means that everyone can read entries in the database just by participating in the network. If you want to change something in the database, you have to create a so-called transaction which has to be accepted by all others. The word transaction implies that the change you want to make (assume you want to change two values at the same time) is either not done at all or completely applied. Furthermore, while your transaction is being applied to the database, no other transaction can alter it.
Blockchain is a globally shared database that stores transactions. (Brilliant) means that everyone can read the entries in the database by joining the network of blockchain nodes. If you want to change something in the database, you have to create a "transaction" that must be accepted by all other nodes. The word Transaction means that the changes you want to make to the database are either completely invalidated or fully accepted. Further, once your transaction is applied to the database, it will not be changed by other exchanges.
2. Block
One major obstacle to overcome is what (in Bitcoin terms) is called a “double-spend attack.
For the blockchain, the most important obstacle to overcome is double spending.
Transactions are not guaranteed to be included in the next block or any specific future block, since it is not up to the submitter of a transaction, but up to the miners to determine in which block the transaction is included.
The transaction cannot be guaranteed to be included in the next block, or in a specific future block. Because it is not up to the submitter of the transaction but to the miner, the miner decides which block the transaction will be included in inside.
3.The Ethereum Virtual Machine
In the Ethereum chain, EVM is the operating environment of the contract.
It is not only sandboxed but actually completely isolated, which means that code running inside the EVM has no access to network, filesystem or other processes. Smart contracts even have limited access to other smart contracts.
Evm is not only sandboxed but also completely isolated, meaning that the environment where the code runs has no network permissions, no file system access permissions, and no other process access permissions. Contracts even restrict access to other contracts.
4. Accounts
There are two types of accounts: External accounts. Contract accounts.
External account: An account controlled by public and private keys. The address is derived from the public key.
Contract account: controlled by the contract code. The contract code is stored together with the account. The contract address is determined when the contract is created (determined by the address and nonce of the contract creator)
Regardless of whether or not the account stores code, the two types are treated equally by the EVM.
Regardless of whether the account stores code (regardless of external accounts and contract accounts), both types are treated equally by Evm.
Every account has a persistent key-value store mapping 256-bit words to 256-bit words called storage.
Each account has a persistent key-value object storage, mapping 256 characters to 256 characters.
Furthermore, every account has a balance in Ether (in “Wei” to be exact, 1 ether is 10**18 wei) which can be modified by sending transactions that include Ether.
Furthermore, each account has an eth balance, which can be modified by transactions involving eth.
5.Transactions
A transaction is a message that is sent from one account to another account (which might be the same or empty, see below). It can include binary data (which is called “payload”) and Ether.
A transaction is a message that can be sent from one account to another. It can contain binary data (payload) and eth.
If the target account contains code, that code is executed and the payload is provided as input data.
If the target account is not set (the transaction does not have a recipient or the recipient is set to null), the transaction creates a new contract.
If the target account is not set, (there is no recipient in the transaction or the recipient is set to null), the transaction will create a new contract. The contract address is derived from the transaction sender and the nonce.
The payload of such a contract creation transaction is taken to be EVM bytecode and executed. The output data of this execution is permanently stored as the code of the contract. This means that in order to create a contract, you do not send the actual code of the contract, but in fact code that returns that code when executed.
The payload of the transaction that creates the contract is executed as Evm bytecode, and the execution output data is permanently stored as the contract code. This means that in order to create a contract, you do not send the actual contract code, but the code when the payload is executed.
While a contract is being created, its code is still empty. Because of that, you should not call back into the contract under construction until its constructor has finished executing.
When the contract is just created, the code of the contract is still empty. Because of this, you should not call any method of the contract until the contract constructor has finished executing.
6. Gas fees.
Upon creation, each transaction is charged with a certain amount of gas that has to be paid for by the originator of the transaction (tx.origin)
Once created, each transaction is charged a certain amount of gas, which must be paid by the transaction originator (tx.origin)
While the EVM executes the transaction, the gas is gradually depleted according to specific rules. If the gas is used up at any point (i.e. it would be negative), an out-of-gas exception is triggered, which ends execution and reverts all modifications made to the state in the current call frame.
When the virtual machine executes the transaction, the gas will be gradually exhausted according to specific rules. If gas is exhausted at any point during execution, an out-of-gas exception will be triggered, and execution will end, rolling back all the modified state in the current call frame.
This mechanism incentivizes economical use of EVM execution time and also compensates EVM executors (i.e. miners / stakers) for their work. Since each block has a maximum amount of gas, it also limits the amount of work needed to validate a block.
This mechanism incentivizes the economic use of EVM execution time and compensates EVM executors (miners or stakers) for their work.
Since each block has the maximum amount of gas settings, it means that the workload of verifying blocks is also limited.
Since EVM executors can choose to include a transaction or not, transaction senders cannot abuse the system by setting a low gas price.
Since the EVM executor can choose to include a transaction or not when packaging, the transaction sender will not set a very low gasprice to abuse the system.
7. Storage, Memory and the Stack
Each account has a data area called storage.
Each account has a data area called storage. It is the storage where functions call each other. Storage is a 256-bit and 256-bit key-value mapping.
It is not possible to enumerate storage from within a contract, it is comparatively costly to read, and even more to initialise and modify storage.
It is impossible to enumerate storage inside the contract, because reading will use relatively high overhead costs, and initialization and modification will be more expensive.
Because of this cost, you should minimize what you store in persistent storage to what the contract needs to run.
Store data like derived calculations, caching, and aggregates outside of the contract. A contract can neither read nor write to any storage apart from its own.
Therefore, the calculation, caching and cumulative calculation of stored data must be performed outside the contract. A contract cannot arbitrarily read the storage of other accounts except its own storage.
The second data area is called memory , The second data area is called memory. Each message call will get a new memory.
Memory is linear and can be addressed at byte level, but reads are limited to a width of 256 bits, while writes can be either 8 bits or 256 bits wide.
Memory is a linear data structure that can be addressed at the byte level, but the read width is limited to 256 bits. The write width can be 8 bits or 256 bits.
Memory is expanded by a word (256-bit), when accessing (either reading or writing) a previously untouched memory word (i.e. any offset within a word). At the time of expansion, the cost in gas must be paid. Memory is more costly the larger it grows (it scales quadratically).
When accessing (reading or writing) a previously untouched memory word (ie, any offset within a word), the memory extends by one word (256 bits). When building out, gas costs must be paid. The more memory grows, the higher the cost (scales quadratically).
The EVM is not a register machine but a stack machine, so all computations are performed on a data area called the stack.
The virtual machine EVM is not a registration machine but a stack machine, so all calculations will be performed in the stack (stack).
Access to the stack is limited to the top end in the following way: It is possible to copy one of the topmost 16 elements to the top of the stack or swap the topmost element with one of the 16 elements below it.
Access to the stack is limited to the top by either copying one of the topmost 16 elements to the top of the stack, or swapping the topmost element with one of the 16 elements below it.
All other operations take the topmost two (or one, or more, depending on the operation) elements from the stack and push the result onto the stack. All other operations take the top two (or one, or more, depending on the operation) elements from the stack. depending on the operation) elements and push the result onto the stack.
Of course it is possible to move stack elements to storage or memory in order to get deeper access to the stack, but it is not possible to just access arbitrary elements deeper in the stack without first removing the top of the stack.
In order to get deeper stack data, it is feasible to move the stack data to storage or memory. It is impossible to access the data at the bottom of the stack without first removing the data at the top of the stack.
Instruction Set instruction set
The instruction set of the EVM is kept minimal in order to avoid incorrect or inconsistent implementations which could cause consensus problems. In order to avoid incorrect or inconsistent practices that cause consensus problems, the EVN virtual machine instruction set maintains an up-to-date quantity.
Message Calls
Contracts can call other contracts or send Ether to non-contract accounts by the means of message calls.
Message calls are similar to transactions, in that they have a source, a target, data payload, Ether, gas and return data. gas, return data.
In fact, every transaction consists of a top-level message call which in turn can create further message calls.
As already said, the called contract (which can be the same as the caller) will receive a freshly cleared instance of memory and has access to the call payload - which will be provided in a separate area called the calldata. After it has finished execution, it can return data which will be stored at a location in the caller’s memory preallocated by the caller. All such calls are fully synchronous.
As already said, the called contract (or calling contract) receives a brand new memory space and has access to the payload data, which is stored in a separate area called calldata. After it finishes executing, the returned data will be Stored in the memory space previously allocated by the caller. These calls are asynchronous.
Calls are limited to a depth of 1024, which means that for more complex operations, loops should be preferred over recursive calls. Furthermore, only 63/64th of the gas can be forwarded in a message call, which causes a depth limit of a little less than 1000 in practice.
The depth of calls is limited to 1024, which means that for more complex operations, loops should be preferred over recursive calls. Also, only 63/64 gas can be forwarded in a message call, which in practice results in a depth limit of slightly less than 1000.
Delegatecall and Libraries
There exists a special variant of a message call, named delegate call which is identical to a message call apart from the fact that the code at the target address is executed in the context (ie at the address) of the calling contract and and do msg.sender not msg.value change their values. There is a special variant of message call called delegatecall, which is considered as a message call --- the target address contract code is executed in the context of the calling contract, msg.sender and msg. value has not changed.
This means that a contract can dynamically load code from a different address at runtime. Storage, current address and balance still refer to the calling contract, only the code is taken from the called address. Load their code into their own runtime environment. Storage, current address, and balance still point to the calling contract, just load the code of the called contract.
This makes it possible to implement the “library” feature in Solidity: Reusable library code that can be applied to a contract’s storage, e.g. in order to implement a complex data structure.
This mechanism provides the possibility for Solidity to implement library functions: reusable library codes can be applied to contract data to implement a complex data structure.
Logs
It is possible to store data in a specially indexed data structure that maps all the way up to the block level.
Create
Contracts can even create other contracts using a special opcode (ie they do not simply call the zero address as a transaction would). Contract settings can create a new contract through a specific opcode.
The only difference between these create calls and normal message calls is that the payload data is executed and the result stored as code and the caller / creator receives the address of the new contract on the stack. The result of payload execution is stored as code, and the creator or caller receives the address of a new contract.
Deactivate and Self-destruct
The only way to remove code from the blockchain is when a contract at selfdestruct that address performs the operation.
The remaining Ether stored at that address is sent to a designated target and then the storage and code is removed from the state. Removing the contract in theory sounds like a good idea, but it is potentially dangerous, as if someone sends Ether to removed contracts , the Ether is forever lost. The remaining eth will be sent to the target address set in advance, storage, and the code will be removed from the state. The exit contract sounds good in theory, but there is a potential risk that if someone sends eth to the exit contract, the eth will disappear forever.
Even if a contract is removed by selfdestruct, it is still part of the history of the blockchain and probably retained by most Ethereum nodes. So using selfdestruct is not the same as deleting data from a hard disk.
Although the contract is removed through selfdestruct, it is still part of the history of the blockchain and is likely to be held by most eth nodes. So the concept of selfdestruct is completely different from deleting from disk.
If you want to deactivate your contracts, you should instead disable them by changing some internal state which causes all functions to revert. This makes it impossible to use the contract, as it returns Ether immediately.
If you want to deactivate your contract, you should change their internal state so that all functions revert to disable it, which makes it impossible to use this contract, because it will return eth immediately.
Precompiled Contracts
There is a small set of contract addresses that are special: The address range between 1 and (including) 8 contains “precompiled contracts” that can be called as any other contract but their behaviour (and their gas consumption) is not defined by EVM code stored at that address (they do not contain code) but instead is implemented in the EVM execution environment itself.
EVM system contracts, precompiled contracts, are executed in the EVM execution environment itself, and are not affected by gas.