Now we monitor the situation so that the number of Ka coins is at least equal to n before the transfer transaction. However, although this solves the scarcity problem, there is no information about who can send Alice’s coins (for now, anyone can do this, as long as you do not violate the quantity limit rule).
Suggestion #3: Combining scarcity and access control
We solve this problem by using the verify_sig digital signature mechanism before checking the balance, which means that Alice uses her private key to sign the transaction and confirm that she is the owner of her coins.
Blockchain programming languages
Existing blockchain languages face the following problems (all of which were solved in Move (note: unfortunately, the author of the article only refers to Ethereum in his comparisons, so you should consider them only in this context. For example, most of the following are also solved in EOS )):
Indirect representation of assets. An asset is encoded using an integer, but an integer value is not the same as an asset. In fact, there is no type or value representing bitcoin / ether / ! This makes it difficult and error-prone to write programs that use assets. Patterns such as passing assets to/from procedures or storing assets in structures require special support from the language.
The deficit is not expandable. Language represents only one scarce asset. In addition, the defense against scarcity is hardwired directly into the semantics of the language itself. The developer, if he wants to create a custom asset, must carefully control all aspects of the resource himself. These are exactly the problems of Ethereum smart contracts.
Users issue their assets, ERC-20 standard tokens, using integer numbers to determine both the value and the total supply. Whenever new tokens are created, the smart contract code must independently check that the issuance rules are met. In addition, the indirect representation of assets leads, in some cases, to serious errors - duplication, double spending, or even complete loss of assets.
Lack of flexible access control. The only access control policy currently in place is a signature scheme using asymmetric cryptography. Like scarcity protection, access control policy is deeply embedded in the semantics of the language. But how to extend the language to allow programmers to define their own access control policies is often a very non-trivial task.
This is also true for Ethereum, where smart contracts do not have native support for cryptography for access control. Developers must manually write access control, for example, using the onlyOwner modifier.
Even though I am a big fan of Ethereum, I believe that asset properties should be natively supported by the language for security purposes. In particular, passing Ether into a smart contract enables dynamic dispatch, which has introduced a new class of bugs known as re-entrancy vulnerabilities. Dynamic dispatch here means that the code execution logic will be determined at run time (dynamic) and not at compile time (static).
Thus, in Solidity, when contract A calls a function of contract B, contract B can run code that was not intended by the developer of contract A, which can lead to reentry vulnerabilities (contract A accidentally executes the function of contract B to withdraw money before the actual deduction account balances).
Move Language Design Fundamentals
Resources of the first order
At a high level, the interaction between modules/resources/procedures in the Move language is very similar to the relationship between classes/objects and methods in OOP languages.
Modules in Move are similar to smart contracts in other blockchains. The module declares resource types and procedures that define rules for creating, destroying, and updating declared resources. But all this is just conventions (“jargon”) in Move. A little later we will illustrate this point.
Move adds flexibility to Libra through scripting. Every transaction in Libra includes a script, which is actually the main procedure of the transaction. The script can either perform one specified action, for example, making payments to a specified list of recipients, or reuse other resources, for example, by calling a procedure that defines common logic. This is why Move transaction scripts offer a lot of flexibility. A script can use both one-time and recurring behaviors, while Ethereum can only execute recurring scripts (calling a single smart contract method). The reason it is called “repeated” is because smart contract functions can be executed multiple times. (note: here the moment is very delicate. On the one hand, transaction scripts in the form of pseudo-bytecode are also in Bitcoin. On the other hand, as I understand it, Move expands this language, in fact, to the level of a full-fledged smart contract language).
The Move executable format is bytecode, which, on the one hand, is a higher-level language than assembler, but lower-level than source code. The bytecode is checked in run-time (on-chain) for resources, types, and memory safety using a bytecode verifier and then executed by the interpreter. This approach allows Move to provide the security of source code, but without the compilation process and the need to add a compiler to the system. Making Move a bytecode language is a really good idea. It does not need to be compiled from source, as in the case of Solidity, there is no need to worry about possible failures or attacks on the compiler infrastructure.
We are aiming to make the checks as light as possible as it is all on-chain off-chain static verification tools. Although this is more preferable, the development of verification tools (as a separate toolkit) has been postponed for the future, and only dynamic verification in run-time (on-chain) is currently supported.
Move modules provide data abstraction and localize critical resource operations. The encapsulation provided by the module, combined with the protection provided by the Move type system, ensures that properties set on module types cannot be violated by code outside the module. This is a well-thought-out abstraction design, meaning that the data inside the contract can only be changed within the framework of the execution of the contract, but not from the outside.