The current mpc NEAR contract provides two functionalities: protocol management and aggregator of signatures. Protocol management will remain on NEAR, but the aggregator of signatures should be extended to smart contracts on all blockchains we support, starting from Ethereum.
The aggregator of signatures part of the smart contract has major entry points of sign and respond, and every internal method used by these functions. Ethereum doesn't support asynchronous contract execution, so sign and query sign results should be separated into two APIs. Theoretically, it's possible to sign and recursively query sign results instead of query on the client side, but that'll be very expensive
Besides the smart contract part, the mpc node needs to know sign requests are coming in (indexer) and call the Ethereum contract respond (gateway). This issue will implement them as a prototype, but in a future task we should refactor it to an extensible way so that we can add other chain support later
The current mpc NEAR contract provides two functionalities: protocol management and aggregator of signatures. Protocol management will remain on NEAR, but the aggregator of signatures should be extended to smart contracts on all blockchains we support, starting from Ethereum.
The aggregator of signatures part of the smart contract has major entry points of
signandrespond, and every internal method used by these functions. Ethereum doesn't support asynchronous contract execution, so sign and query sign results should be separated into two APIs. Theoretically, it's possible to sign and recursively query sign results instead of query on the client side, but that'll be very expensiveBesides the smart contract part, the mpc node needs to know sign requests are coming in (indexer) and call the Ethereum contract
respond(gateway). This issue will implement them as a prototype, but in a future task we should refactor it to an extensible way so that we can add other chain support laterTask List