As mobile internet technology continues to mature, the emergence of blockchain technology represents the upcoming post-mobile era. In fact, blockchain is a critical innovation for our generation. Despite currently being in an early stage of development (to the extend of being percieved as mysterious by the public), blockchain has a promising future. Subsequent to the previous two blockchain articles I published, this article aims to elaborate on the heart of blockchain – smart contracts.
What is a smart contract
The term “smart contract” was first coined by Nick Szabo in 1995, loosely defining it as a digital contract that is executed automatically.
A sales contract can be used as simple example of a smart contract. Two parties, a buyer and a seller, agree to terms of sale, such as price, delivery option and payment method. Once the seller has commited to send products to the buyer, the smart contract is updated, and the buyer’s payment is made automatically. Whenever a predetermined condition or term is met (such as confirmation of a sent parcel), the smart contract will execute in accordance.
Blockchain technology is evolving rapidly, with more value being generated by its applications with each iteration. Smart contracts are not only automated traditional contracts, but play a critical role in the world of blockchain. Below, I explore the future of this revolutionary technology through a technical analysis of Ultrain’s Blockchain 3.0 smart contracts.
Smart contract technical analysis
Ultrain's contract system does not allow other contract’s code to be embedded in custom contracts, but Ultrain does provide three methods to call code from other contracts, which we explore below.
The Action.requireRecepient() method requires an action from a specified recipient. This command calls the deployed smart contract with a specified name.
As an example below, we have written and deployed two contracts. In Figure 1, a contract was deployed on account “jack”, requiring authentication (Action.requireAuth()) from“rose”. The other contract, seen in Figure 2, was deployed on account “rose”and uses Action.requireRecipient() to validate the received notification from and “jack”.
We can test our calls by initiating a transaction. If everything runs smoothly, the log will show that both “jack” and “rose” recipient methods were called.
We learn from this that:
（1）The recipient with the name “jack” has been called.
（2）The parameter transmitted is inconsistent with the parameter,“messi”, initiated by the transactions.
（3）Both the recipient methods of “rose” and “jack” will be called within the same transaction.
（4）Both “rose” and “jack” control their own permissions
Based on the testing result of Action.requireRecepient(), we can see that requireRecepient() has some limitations. Action.sendInline() is a method that solves this issue and allows any parameter to be called. Here is another explanatory example, again with two contracts, “rose” and “jack”:
Contract “rose” uses the Action.sendInline() method and delivers arbitrary parameters (params) to “jack” once executed.
We can see in the execution log that “jack”’s “name”value has changed in accordance “params”specified in “rose”.
This indicates that sendInline() can be used to call any method in any contract. Permissions are controlled by each contract independently, similar to the previous example, and the change is executed within the same transaction.
We saw in the previous examples that the actions specified in requireRecepient() and sendInline() are executed within the same transaction. This leaves the possibility for a mistake to result in the failure of an entire transaction. Transaction.send() is a perfect solution to this potential issue.
The following picture demonstrates how this method is used:
We can execute the deferred methods specified in “rose”even after the contract has been deployed. Please note, the active right of rose to must be assigned to utrio.code, otherwise the request will not successfully exeucte.
Once this method is conducted succesfully, we see rose’ log informtion（see Figure 3), but where is jack’s? We find it within the nodes (see Figure 4).
From above we can see that Transaction.send() has the following charateristics:
1）Transaction.send() can call jack from any method.
2) the method allows execution outside of the same transaction
3）A called method can transmit any parameter
4）when the jack method is being called, it has the same permissions as rose at initiation
The table below recaps the charateristics of the methods described above. Each method has different strengths and weaknesses, and are therefore suited to their own specific circumstances.
In summary, our analysis above clearly demonstrates the important role of smart contracts play in the Blockchain 3.0 era, by allowing flexible and secure computations on a decentralized system. Hopefully you have also glimpsed the power of Ultrain’s smart contracts.
Ultrain, a pioneer of next-gen blockchain projects, has made many improvements and breakthroughs in existing smart contract technology. Ultrain contracts are far beyond the requirements of traditional contracts and can realize increasingly complex business logic. They can be used for technical intercommunication that builds bridges between various industries. For this reason, blockchain technology is an essential component required for creating a business empire with high performance, low cost, high service quality and support for large-scale data assetization.