Inter-Contract Communication

[stephenpdeos]

Problem

Opportunity: What are the needs of our target user groups?

As a developer, I need the ability to build contract actions that depend on the outcome of other contract actions (sync calls, blocking calls) to deliver a better user experience when signing certain types of transactions. Contract to contract interaction (“inline actions”) is currently an asynchronous system. When an action of contract A wishes to call an action of contract B the inline action is executed after the action of contract A has finished execution. On other smart contract platforms, specifically any EVM-based network, these are synchronous so A can wait to receive the results of B and continue it’s own execution based on those results.

The lack of synchronous calls is an impediment for smart contract developers to compose complex transactions across multiple contracts. Furthermore, the complexity and resulting confusion around the execution order of inline actions (which could trigger more inline actions or notifications via require_recipient) can lead to developers unknowingly creating attack vectors in their code.

What this results in is that people are strongly motivated to create monolithic contracts rather than modularizing them and creating more interoperability between separate contracts (perhaps even managed by different entities).

This limitation cascades into less sensible APIs between contracts and higher likelihood to break on version upgrades.

There are various features we want to build (including things like simplifying our resource model, contract pays, improved account/permission management, better token standards) that cannot be designed in an elegant way because of the lack of sync calls.

More than just the odd programming patterns required to do the simple tasks (i.e., weird callback patterns), some types of systems just can not be built altogether.

Target audience: Who is the target audience and why?

All consumers of our technology.

• dApp developers for better transaction composition, reuse of existing contracts in a modular fashion, and simpler patterns for accessing derived state defined by smart contracts.
• dApp users for better simpler UIs based on objective of actions rather than the inline action call pattern (the naming is poor, as the inline action only executes after the full execution of the containing action).

Strategic alignment: How does this problem align with our core strategic pillars?

Our core pillar of "Blockchain made easy" strongly aligns with sync calls with the largest benefit going to smart contract developers new to the EOSIO Ecosystem, particularly if they have written smart contracts previously where sync calls were part of the core protocol.

There is however a slight risk of disruption to seasoned EOSIO Smart Contract developers because of the new conventions introduced with async calls.

Context

Competitors: Who are our top competitors (up to 5) and why? How do they solve this problem today?

All EVM-based networks support this, which enables modularity of contracts being used together.

Product differentiation: what would make our solution different?

Faster transactions by the means of pipelining the initialization of other smart contracts, retaining the same context frame between invocations and asynchronous invocation to allow for more work to be done while getting the result, we get sync calls for free with this model.

Audience definition

• Smart contract developers from other ecosystems
• EOSIO smart contract developers

Solution

Solution name: How should we refer to this product opportunity?

Async Calls

Purpose: Define the product’s purpose briefly

To enable more flexible implementation of smart contracts in order to have more modular, less monolithic implementations

Success definition: What are the top metrics for the product (up to 5) to define success?

We can create smart contracts that interact with other smart contracts in the same execution context (i.e., running of an action). We should be able to call 'read-only' actions of another (or the same) smart contract for v1. In the future we can add the ability to do read-write actions.

Assumptions

We need to do some work on chainbase to make the API asynchronous for reads and writes of DB state.

Risks: What risks should be considered? https://www.svpg.com/four-big-risks/

Business Objectives/Functionality

Smart contracts should be able to have a new way of calling actions within an action context (send_async). This function should return a handle to be used by another host function async_result, which will populate a buffer given and return the bytes written or return -1 in the case that the async call has not yet finished.

For CDT we should have quality abstractions over this to have a promise/future based system for async calls and a blocking pattern for sync calls.

Features/Epics

• Asynchronous chainbase API
• Leap pipelining and double buffering of linear memory for fast invocation of other smart contracts
• Leap/ EOSVM changes to use the same linear memory as calling context when designated.
• Leap host functions to facilitate and expose new execution model.
• CDT abstractions

User stories

As a dApp developer I can call into other smart contracts and execute 'read-only' actions.
As a dApp developer I can define my state API to be exposed to the outside world via 'read-only' actions. This allows for better abstraction layers to be maintained and for dApp devs to define their own access rules.
As a dApp developer I can create complex systems with multiple actions being invoked in the same context.
As a dApp developer I can create complex actions that allow for multiple aggregated queries of other contracts.

Additional tasks

• Proposal: Async Actions #63

Timeline

Cost

Open questions