RFC: Native execution via connected Orchestrators and Canister repositories

[supragya]

Problem motivation

Under the current scenario, we take native execution, much for granted in terms of its real world structuring. In the current design, whenever we build for native the token program, the dependent call (in token transferring context) to wallet program is resolved via a function call within rust. That essentially means that when native version of token is built, wallet is statically linked. However, in real world that may not always be possible due to following scenarios:

1. Disclosure: If program PRG1 calls another program PRG2 whose source may not be disclosed / is from another developer, this kind of static linking may not be easy / ergonomic.
2. Authorities: PRG2 is actually held in secrecy (behind closed walls) and world only knows of its ProgramIdentifier.
3. Compilation overhead: PRG1 has to statically link all the possible programs that may ever be involved in any execution path leading to long compilation times.
4. Tooling / Reproducible build: PRG1 also has to maintain the right build tools to build PRG2 so the program identifier doesn't deviate, a.k.a the problem of hermetic reproducible builds.

In essence, the current design of static linking is not a very good idea.

The main idea: Orchestrator based native execution

Each native execution can essentially be modeled as a function such as:

NativeExec(prg: ProgramIdentifier, args: A) -> (ret: R, tapes: SysTapes)

where A is a message understood by prg and R is a message return type that prg returns. Much of the times, it is an element of an enum. tapes is the execution tapes that was seen during this execution and holds tapes for all involved sub-program as well.

During native execution of any program prg, tapes[prg] is being populated, but since there may be sub-programs that were executed in the process, tapes may have keys more than just prg.

Assume there exists two entities: Orchestrator and Canister defined as follows:

• Orchestrator is an online service that serves as a resolver for NativeExec, essentially taking in (prg, args) as request and return (ret, tapes). This endpoint may be called by users (humans) or canisters. Orchestrators know of their own set of locally available resolver "canisters" (the local BLOB repository) as well as a few other orchestrators should they not be able to resolve NativeExec themselves.
• Canister is just a packaged version of a mozak-vm compatible "program" that has added gRPC endpoint that can be hit by their "default orchestrator" for resolving request. In turn, these canisters know of their "default orchestrator" and can query them for helping their sub-resolutions.

In such a design, any orchestrator (as long as it is connected to the web of orchestrators) can resolve NativeExec.

Example: AMM execution

Assume the following execution:

AMM (transfer 100 USDC from AMM to Bob for 100 USDT received from Bob)
  USDC (debit 100 USDC from AMM, credit Bob)
     WALLET (signature verification: AMM)
  USDT (debit 100 USDT from Bob, credit AMM)
     WALLET (signature verification: Bob)

User asks native generation for system tapes from Orchestrator 2. Here is how it will look:

User -> Orc2: NativeExec(AMM, {tfr, 100USDT, USDC, Bob})
Orc2: Can't resolve AMM locally
Orc2 -> Orc3: Discovery(AMM) -> unresolved
Orc2 -> Orc1: Discovery(AMM) -> success
Orc2 -> Orc1: NativeExec(AMM, {tfr, 100USDT, USDC, Bob})
Orc1 -> Canister_AMM: NativeExec(AMM, {tfr, 100USDT, USDC, Bob})
Canister_AMM -> Orc1: NativeExec(USDC, {tfr, 100USDC, Bob})
Orc1: Can't resolve USDC locally
Orc1 -> Orc2: Discovery(USDC) -> success
Orc1 -> Orc2: NativeExec(USDC, {tfr, 100USDC, Bob})
Orc2 -> Orc3: NativeExec(USDC, {tfr, 100USDC, Bob})
Orc3 -> Canister_USDC: NativeExec(USDC, {tfr, 100USDC, Bob})
Canister_USDC -> Orc3: NativeExec(WALLET, {sigverify, 100USDC, AMM})
... discovery steps
Orc3 -> Orc2: ...
Orc2 -> Orc1: ...
Orc1 -> Canister_WALLET: NativeExec(WALLET, {sigverify, 100USDC, AMM}) -> (True, SysTapes)
Orc1 -> Orc2 -> Orc3 -> Canister_USDC: resolved (True, SysTapes)
CanisterUSDC -> Orc3: NativeExec(WALLET, {sigverify, 100USDC, AMM}) -> (True, SysTapes)
Orc3 -> Orc2 -> Orc1 -> Canister_AMM: resolved (True, SysTapes)
Canister_AMM -> Orc1: NativeExec(USDT, {tfr, 100USDT, AMM})
Orc1: Resolved USDC locally
Orc1 -> Canister_USDT: NativeExec(USDT, {tfr, 100USDT, AMM})
Canister_USDT -> Orc1: NativeExec(WALLET, {sigverify, 100USDT, Bob})
Orc1 -> Canister_WALLER: NativeExec(WALLET, {sigverify, 100USDT, Bob}) -> (True, SysTapes)
Orc1 -> Canister_USDT: resolved (True, SysTapes)
Canister_USDT -> Orc1: resolved (True, SysTapes)
Orc1 -> Canister_AMM: resolved (True, SysTapes)
Canister_AMM -> Orc1: resolved NativeExec(AMM, {tfr, 100USDT, USDC, Bob}) -> (True, SysTapes)
Orc1 -> Orc2 -> User: Final output (True, SysTapes)

[eightfilms]

From a preliminary read, no major complaints or improvements from me. Some questions that I raised in private conversation with @supragya:

While the comment that there are drawbacks to the current native execution is done is right, the current design is assuming that native executions can be done offline in a trusted environment. What the RFC is proposing is how native executions could work online; which previously we had discussed in a hand-wavey way.

I had one question - which was about the possibility of a compromised canister. Orchestrators would not know of a 'previously good turned bad' canister, but @supragya rightfully pointed out that proof generation would fail if a compromised canister had executed code in an unexpected manner.

Will add more, if I find/think of anything.