Transaction Signature
The above figure demonstrates the default signing process of our 2-3 default scheme, which requires 2 participants: User Device and Hot Server. The entire life cycle of signing carries a unique Session ID to identify a single round of information. The message is passed through the message queue (MQ) using end-to-end encryption. It uses token authentication to ensure that each party can only obtain the messages of its channel. Hot Server is a permanent service that can receive information anytime through a message subscription.
The specific steps of Keygen are as follows:
The client initiates a signing request to the server and obtains the Session ID.
The server responds to the request, generates a Session ID, and returns it to the client.
The client broadcasts a message to MQ with Session ID to initiate signing. Meanwhile, the signing process is started asynchronously locally.
The MQ receives the request, analyzes the user token, and checks whether it is legal in the user center.
If the authentication is passed, proving it is a routine request from the client side. Otherwise, it directly refuses to return.
The MQ broadcasts the initiation message to the channels subscribed by Hot Server. When Hot Server receives the message, it starts the signing process asynchronously.
The MQ returns a successful broadcast response, and the client starts the MPC protocol interaction process. Otherwise, a signing exception would occur.
The User and the Hot Server exchanged MPC information several times by MQ. Then, the Hot Server discards the signature information in TEE and only records the signature result to DB.
The same signature information will be obtained when the client completes the MPC interaction.
The client broadcasts the signature information to the blockchain, and the signing process ends.