Deep dive into the significance of internal function calls and why they are crucial for developers to understand. This post unpacks the mechanics of internal function calls within programming languages, shedding light on their impact on code performance and efficiency.
What is it?
In the blockchain realm, internal function calls play a crucial role in enabling seamless interaction and communication among various segments of a smart contract. Unlike external calls, these internal operations occur within a single contract, facilitating the execution of complex transactions and intricate logic. They are instrumental in enabling the implementation of advanced decentralized applications (dApps) by promoting data sharing, action execution, and function triggering within the contract, ensuring efficient blockchain system operation.
Advanced blockchain use cases, such as Account Abstraction, significantly increase the volume of internal function calls. In fact, some suggest, as discussed in this thread, that TPS (Transactions Per Second) is a faulty metric to measure blockchain throughput as it is not directly connected to the computation complexity, given that some transactions include significant computation within.
A screenshot from Starkscan illustrating multicall transactions are common on Starknet
On-chain data is very expensive
So, why haven’t you heard of this before? The short answer is that obtaining this data through today’s on-chain data access is very expensive. Retrieving internal function calls requires obtaining the entire trace of the transaction, leading to an absurd amount of RPC calls (not to mention rate limits and shortages). To put some numbers here, gaining visibility to all of Arbitrum internal transactions requires more than 150 M RPC calls which automatically sends the user to the highest pricing tier.
As account abstraction gains more traction, promising to provide an excellent user experience for Web 3.0 users, the need to unravel and make sense of complicated transactions is already upon us.
A simple example that highlights the complexity brought about by account abstraction is the following question:
“Who are the dApp’s users?”
At first glance, it might seem like a trivial question since all transactions are recorded on-chain. However, given that the Entrypoint contract is now the origin of all user operations, it seems impossible to associate a user transaction with its outcome, making it challenging to analyze and assess the effectiveness of the subsidy accurately.
A screenshot from Polyscan illustrating that all interactions with xFANTV seems to originate from a Bundler
Tracking without querying
One of the core strengths of SendBlocks lies in its ability to streamline the complexities associated with tracking any activity on the blockchain without the need to query the entire trace. Leveraging SendBlocks’ on node computation capabilities, the Function can enrich any incoming transaction with all the data needed to completely understand who sent the original transaction and establish a well-structured decision-making process (check out this example).
Unfolding these transactions has great significance. Understanding who are the users interacting with a dApp is critical in terms of security (and reducing counterparty risk), marketing and organic growth, to more sophisticated needs such as ROI calculations for gas subsidies. As more complex computations are performed on-chain, new, deeper, and faster data processing methods are required.
Try SendBlocks to build the next generation of blockchain-based applications.
