[ProjectTracking]: Protocol extensions to support the chain signatures project (yield/resume)

[akhi3030]

Goals

Background

The chain signatures project is a high priority project for the NEAR ecosystem. In order to support the project, we need to extend the NEAR protocol to provide support for yielding smart contract execution.

Why should NEAR One work on this

This project is a requirement in order to launch the chain signatures project which stands to onboard many users to NEAR and open up many different types of application scenarios.

What needs to be accomplished

We need a couple of new host functions to the NEAR protocol and implement them. The precise API of these host functions is still under discussion. At a high level, we need two new host functions.

• yield: which allows a smart contract to delay "execution" till some point in the future.
• resume: which allows a smart contract to resume a delayed "execution".

Note that we are not talking about actually suspending wasm execution here. We just need a mechanism for the smart contract to be able to delay responding to a request that it has received.

Main use case

The most important use case is fastauth. Using these host functions, a smart contract can implement multi-party signing contract.

• The signer contract exposes a fn sign_payload(payload, ...) function which other customer contracts can call to request some payload be signed.
• The signer contract creates some internal state and then calls yield.
• Off chain indexers are monitoring the state of the signer contract. They detect the change in state; start computing the signature; and when ready, call another function function that the signer contract exposes called fn signature_available(signature, ...).
• In the implementation of fn signature_available(signature, ...), the signer contract, validates the signature and if correct, calls yield. When calling yield, the signer contract is able to send a response to the customer contracts with the signature.

Links to external documentations and discussions

• This issue is discussing the API and high level design.

Additional resources will be added here such as NEP, etc. when they become available.

Estimated effort

It is expected that the core and the runtime teams will be working on this project. The people actively working on this project are: @akhi3030, @saketh-are, and @walnut-the-cat.

The fastauth project plans on launching by end of Q1 2024. For the time being, we have offered the fastauth project a hacky workaround that they can use for the launch. As such we currently do not have a strict deadline for this project currently. However, we still need to deliver this as quickly as possible.

We are still debating the precise API.

The coding estimate is about 1 month once we have agreed upon the API.

Assumptions

There are no specific assumptions that this project is making.

Pre-requisites

None that I am aware.

Out of scope

Nothing comes to mind.

Task list

Tasks

Preview Give feedback

1. Agree on API
2. Create a NEP
3. Implement the API
4. Get the code released into testnet
5. Get the code released into mainnet

[walnut-the-cat]

Near core project tracking issue: near/nearcore#10210

[akhi3030]

Update on November 30th, 2023: We have a high level agreement on the API. We still have not agreed on the precise API at the host function level yet though. Unfortunately, Both Akhi and the Saketh were ill and progress on this slowed down. We are still hoping to meet our deadline of being code complete by middle of february. But things are looking more tight now.

[akhi3030]

We have agreed on the API and Saketh has a POC of the initial basic version. We are now targeting to have this work on testnet by end of Q1.

[akhi3030]

Lots of engineering work already done.

• Possible to yield and resume execution
• Support for fixed length timeouts

Remaining misc. work should be done by EOW.

Simonas is working on estimating gas costs and bounding congestion. We have an initial PR to estimate most of the gas costs. There are ongoing discussions on bounding congestion. There might not be additional work on it.

[akhi3030]

The NEP is ready to be reviewed by the protocol working group.

[saketh-are]

#10415 is about to be merged. Outstanding items are documented in #10455, mainly having to do with:

• Properly configuring protocol parameters such as gas costs and the timeout length
• Reworking the trie storage as discussed on Zulip
• Test coverage
• Quality of life improvements on the near-sdk-rs and near-cli fronts

[akhi3030]

• The protocol working group meeting is later today where the NEP is expected to be approved.
• #10415 is now merged and we have some preliminary gas fees
• We still have some still small engineering tasks left around adding support for resharding and testing.
• We estimate the amount of effort left to be about another week.