I. Program Backends on the Internet Computer

The Internet Computer (IC) aims to support a programming experience that is efficient, persistent, and interoperable. Figure 3.1.1 presents the core of backend programming on the IC. Ultimately, the goal is to be inclusive for all languages that can be compiled to WebAssembly, which is a way to run code in multiple languages on the web at flashing speeds. However, the current status quo is to program in Motoko, which fully utilizes the unique features of the IC, such as orthogonal persistence and actor-based programming.

Each actor is programmed in a “.mo” file and deployed to a canister with a 4 GB limit. An actor can modify its local or private state, send messages, and create more actors. First, each canister can communicate with other canisters through asynchronous messages, and each query call takes approximately 10 milliseconds. The query call does not change the state of the queried canister. Second, each canister has a private state that can only be modified by the canister itself. Thus, update calls that change the state of a canister must go through consensus and, on average, take approximately 2 seconds for final execution. Finally, each canister has a single thread of execution without lock-based synchronization, and the IC can run many threads in parallel to scale.

Figure 3.1.1:1 Backend Programming on the Internet Computer

Motoko Playground is a cloud solution for the complete pipeline of backend programming, deployment, and Candid UI testing. To program and deploy the backends on a local computer, DFINITY Canister SDK, Motoko VS Code Extensions, and Vessel Package Manager can be used. Figure 3.1.2 shows the complete pipeline of backend deployment.

Figure 3.1.2: Complete pipeline for backend deployment.

We first run the following code in the terminal.

The .mo file of actors can be found under the folder src, and then the actors can be programmed in Motoko.

Figure 3.1.3: Customize the Actor File

Figure 3.1.4 shows a simple counter actor. The default current value is 0. There are two functions for this actor. The increment function increases the currency value by 88, and the obtained function returns the current value.

Figure 3.1.4: Counter Actor

We then run the following commands to deploy the canister:

Now, we can test the backend by canister call command, which is a “dfinity canister call” followed by the name of the actor and then the name of the function to be executed. In the following command, we first call the get function once, the increment function twice, and the get function once again.

Figure 3.1.5 presents the returns from the canister call. We can see that the current value increases from 0 to 176 after the increment of 88 twice.

Figure 3.1.5: Test by Canister Calls

Figure 3.1.6 represents the same test executed by Candid UI on Motoko Playground. To advance Motoko programming, the Motoko Base Library can be utilized.

Figure 3.1.6: Test by Candid UI on Motoko Playground

ii. Smart Contract Programming: A Comparative Study

In this section, we compare backend programming on the IC and Ethereum. Figure 3.2.1 represents the core of the comparative study. The status quo programming languages for smart contracts on Ethereum and actors on the IC are Solidity and Motoko, respectively. Solidity is object-based programming, and Motoko is actor-based programming. The main difference is that actors process messages in an isolated state, enabling messages to be handled remotely and asynchronously without sharing memories. Remix is the cloud solution for the integrated development environment (IDE) on Ethereum, and Motoko Playground is the analog on the IC. Both provide a complete workspace in the cloud from programming to deploying and testing. For a more complete pipeline that includes customized frontends and much more, we can utilize Truffle Suite for Ethereum and DFINITY SDK for the IC. There is one critical difference for smart contract testing. For smart contracts on Ethereum, a one-click testing blockchain, such as Ganache, can be utilized. For example, truffle develop can be used to develop a testing chain with 10 wallets of 100 ETH each. However, there is currently no testing chain for the IC. To test most functions, the smart contract canister must be deployed to the IC network, which requires the registration of an identity on the IC and cost cycle tokens, as mentioned in Chapter 1. Fortunately, free cycles of 100 USD can be requested from Cycle Faucet for pilot testing. Moreover, identity registration is now supported by a wide range of identity anchor devices, such as iPhone, Yubikey, and Windows hello. Finally, Web3.js is the Application Interface (API) solution for Ethereum, as is Candid UI for IC.

Figure 3.2.1 Smart Contract Programming: A Comparative Study

Figure 3.2.2 shows the analog of the counter actor in Session 1 as a smart contract programmed in solidity. Compared with Figure 3.1.4, we can see that the structure is similar with slight differences in how types of data and queries are specified.

Figure 3.2.2 Counter Smart Contract in Solidity

Figure 3.2.3 shows the same smart contract with input values in Solidity and Motoko. The smart contract further defines three functions with input. The set function sets the current value as input. The increment and decrement functions increase or decrease the current value by input numbers, respectively.

Figure 3.2.3 Counter Smart Contract with Input Values

Figure 3.2.4 presents the user interface (UI) for smart contracts in Solidity and Motoko on Remix and Motoko Playground. Subsequently, interactions with smart contracts are enabled. Notably, the UI on the Motoko Playground distinguishes the query call from the update call, which is a unique feature of the IC. Unlike update calls, the query call does not change the private state of the canister and can be executed at web speed.

Figure 3.2.4: UI on Remix and Motoko Playground

III. Intercanister Call and Autonomous Governance

IC canisters have two unique features: 1) governance: canisters can be the controllers or managers of other canisters; 2) intercanister calls: canisters can build, deploy, and call shared functions with each other. With both features, we will be able to deploy protocols with multicanister interactions and governance and even autonomous canisters without a particular owner. A decentralized governance system can also be designed for the autonomous canisters so that all stakeholders can participate in governance, e.g., proposing, voting and enacting software updates. Such autonomous software is a promising solution for the current monopolization of the internet by big tech. A stakeholder on an autonomous platform is not as affected by abrupt rule changes, such as misuse of data or interruption of services.