Understanding the ways smart contracts call each other

Can contracts call each other? Are message calls similar to transactions?

Hello again 😊. It's nice to have you here. If you have read my previous articles, thank you. If this is your first time reading my article, thank you! You can check out my dashboard to find amazing, and educating articles (especially if you want to understand solidity and blockchain in a very simple way).

Back to our question ❓❓❓

Can contracts call each other? Yes!

Are message calls similar to transactions? Yes!!

According to the doc...

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. In fact, every transaction consists of a top-level message call which in turn can create further message calls.

Breaking it down...

Jane has two friends, Alice and Bob, and she wants to give Bob a gift. Jane is the source, Bob is the target, and the gift is the data payload. Oh, and also, Jane is giving some money along with the gift, and she is using a car to deliver it.

Talking about Bob, he also has a friend, Charlie, to whom he wants to pass on a part of the gift. So, Bob makes another "gift giving" to Charlie. In this case, Bob becomes the source, Charlie is the target, and so on.

When it comes to the world of contracts and Ether, it is similar. Contracts can send Ether (the cryptocurrency used on the Ethereum blockchain) or interact with other contracts by initiating what are called "message calls." These calls are like instructions sent from one contract to another, carrying data (like a gift) and potentially Ether (money). Just like how one friend can pass a gift to another friend who can then pass it to someone else, contracts can initiate message calls to other contracts, which can, in turn, create more message calls, and so on.

Smart contracts can interact with each other in several ways, enabling complex decentralized applications (DApps) and protocols to be built on blockchain platforms like Ethereum. We will be looking at some common methods by which smart contracts can call each other.

Methods by which Smart Contracts call each other

Direct function calls

Smart contracts can directly invoke functions defined in other smart contracts. This is done using the call or send methods, passing the necessary parameters and data. The called contract's function needs to be marked as public or external for it to be accessible from other contracts.
Back to our friends, Alice and Bob 👱‍♀️👱‍♂️;
Alice and Bob have their own special notebooks each. These notebooks contain instructions (functions) on what to do when someone asks them to do something. Now, let's say Alice wants Bob to do something for her.
In a direct function call:

Alice simply opens her notebook and finds the specific instruction (function) she wants Bob to perform.
She picks up the phone and calls Bob, saying, "Hey Bob, could you please do this thing for me?"
Bob listens to Alice and checks his notebook. When he finds the instruction Alice mentioned, he follows it and does what Alice asks.

Relating this to smart contracts;

Alice's notebook is like her smart contract, containing functions she can perform.
Bob's notebook is like his smart contract, with its own set of functions.
Alice calling Bob directly means her smart contract is invoking a specific function in Bob's smart contract.
Bob executes the requested function based on the instructions in his smart contract.

Delegated calls

From Solidity documentation...

There exists a special variant of a message call, named delegatecall which is identical to a message call apart from the fact that the code at the target address is executed in the context of the calling contract and msg.sender and msg.value do not change their values.
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.
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.

Delegated calls are like assigning a task to a coordinator friend, who then decides which specialized friend should handle each part of the task, ensuring efficient completion through collaboration. Similarly, in smart contracts, delegated calls enable one contract to delegate certain tasks to another contract, which then manages the execution across multiple contracts.
Let's see a simple illustration of this.

Relating the illustration to smart contracts;

You, as the initiator, have a smart contract that needs to perform various tasks.
Sarah represents a special smart contract called a "delegate" contract that coordinates tasks.
Each friend's talent corresponds to a function or capability of a different smart contract.
Delegated calls allow your smart contract to delegate certain tasks to the delegate contract, which then distributes the work to other contracts and consolidates the results.

Proxy contracts

Proxy contracts act as intermediaries between multiple contracts. When one contract needs to interact with another, it does so through the proxy contract, which forwards the request to the appropriate destination contract.

Let's look at it simply.

Alice has a favorite restaurant (implementation contract) where she loves to eat her favorite dish. However, she always orders through a food delivery app (proxy contract) without directly contacting the restaurant.

How does this work?

Proxy Contract: This is like the food delivery app. It's what Alice interacts with when she wants to order food. She tells the app what she wants, and it takes care of everything else, including communicating with the restaurant.
Implementation Contract (Restaurant): This is the actual restaurant where Alice's food is prepared. It's where all the cooking and serving happen.

Users engage with the proxy contract and are not required to know the implementation contract. Their interaction solely involves placing orders through the proxy contract.
Note: Multiple apps (proxy contracts) can offer food from the same restaurant (implementation contract) to different users.

In the implementation contract, if you change a variable, let's say slot index 3, within the implementation contract, it will change the storage of slot index 3 in the proxy contract.

Other Methods

On-chain events and listeners: Smart contracts can emit events upon certain conditions being met. Other contracts can listen to these events and react accordingly by calling specific functions in response.

Oracle services: Smart contracts can utilize Oracle services to access external data or perform off-chain computations. These oracles can trigger specific functions in other contracts based on the received data.

Interface contracts: Contracts can define interfaces that specify the functions they expose. Other contracts can then interact with them through these interfaces without needing to know the implementation details.

Each of these methods has its own use cases and trade-offs, and the choice depends on factors such as security, efficiency, and the specific requirements of the decentralized application being developed.

It was fun, right? Alice, Bob, and their friends had fun with us too. Let me know what you think in the comment section. Don't forget to check out my other articles. You would be amazed at what you could learn from them.
Check me out on Twitter and LinkedIn.

See you next time...

Reference: Solidity documentation