[Proposal] FROST implementation compatible with Near

Near Community and nodes Onboard DAO
1

Proposal Type

Wallet Nativeness

Amount Requested (in USDC)

5000 USDC

Payout Address

hotfrog8038.near

Open-Source License

GPLv3

Outcomes & Deliverables

We expect to deliver the following after one month since the beginning of the project:

  • Client-side library: implementation of a client-side library for the FROST protocol compatible with Near in Typescript.

  • Server-side library: implementation of a server-side library for the FROST protocol compatible with Near in Rust.

Solution

This post outlines the proposal for implementing FROST, a threshold signature protocol based on the Schnorr signature scheme, and adapting it to the Ed25519 signature scheme and the Near ecosystem. This protocol is particularly designed for scenarios with a large number of signers, ensuring both efficiency and signer anonymity.

The protocol starts with a Distributed Key Generation, where a secret key is generated that no single participant knows of. Instead, the participants generate shares of that secret key, that they can later use to sign an extrinsic. This is done by using the Pedersen’s variation of the Shamir’s secret sharing scheme, which allows the participants to verify their shares and does not require a trusted dealer. Our solution is:

  • Scalable and cheap: Only a single Ed25519 signature is submitted to the network and is independent of the number of signers.

  • User-friendly: A participant does not necessarily need to fund its account nor pay to send a transaction (the broadcaster account needs to pay for it, but how and if the fee is divided among participants will depend on the use case).

  • Private: The output Ed25519 signature is indistinguishable from any other signature on the network, and the signers are not known because the signing protocol happens off-chain.

Impact to Ecosystem

The goal of the project is to build a working prototype that can be integrated by established wallets of the ecosystem; the goal is not to be another competitor wallet.

This project is useful for any Near based project that wants to implement the functionality it provides, but it is specially suited for wallet developers. Besides that, it can be used as a backend wallet, instead of a front-end user focused wallet, in other applications.

Since the two subprotocols are independent of each other, the DKG protocol can be used as a building block for other use cases, such as ones based on threshold decryption.

Relevance to Onboard DAO

This project provides important wallet infrastructure that will contribute to onboard and retain end users, but also potentially attract institutional users due to the functionality it provides.

Team & Relevant Background

Future Plans

If there is interest in the community, the next step is to actually implement a client (by forking one of the wallets of the Near ecosystem) and a server based on the developed libraries as a Proof of Concept implementation of a threshold signature scheme ready to be utilized by users.

2
  • What do you envision in terms of applications to be built with this?
  • Also do you have an estimated timeline of completion?
  • Does anyone on the team have any experienced building on NEAR?
3

In general, a threshold signature scheme like FROST can replace a multisignature scheme in any application that uses it, since it can have the same function (for example, in multisig contracts - Accounts | NEAR Documentation). Concretely, it can be used to transfer funds of grants like this, to vote in a DAO or to serve as an escrow in a DeFi application, for example.

However, FROST is more powerful and flexible than a multisignature scheme because it is t-of-n instead of n-of-n (which is special case of the former) and it has the following advantages:

  • More scalable and cheaper: Only a single Ed25519 signature is submitted to the network and is independent of the number of signers. This allows for a much greater number of signers since the signing happens off-chain instead of on-chain.

  • More user-friendly: A participant does not necessarily need to fund its account nor pay to send a transaction (the broadcaster account needs to pay for it, but how and if the fee is divided among participants will depend on the use case).

  • More private: The output Ed25519 signature is indistinguishable from any other signature on the network, and the signers are not known because the signing protocol happens off-chain.

The estimated timeline of completion for this project is one month.

The team is only me, and I do not have experience building on Near. However, I do not see that as a problem since Near documentation is exhaustive and developer-friendly.

4

Hi your proposal was approved for May funding

Dm Telegram: Contact @Yuensid on telegram to discuss the next steps
https://near.org/astraplusplus.ndctools.near/widget/home?page=dao&tab=proposals&daoId=onboarddao.sputnik-dao.near&proposalId=305

5

The work has been done and the code can be found here.

It is a fork of the Near CLI that implements the Olaf protocol, allowing to create threshold accounts and threshold signatures with them using out-of-band communication.

A tutorial can be found in the docs.