Verification method for light node participating in Ethereum consensus based on mobile terminal

Abstract

The invention discloses a verification method for a light node to participate in Ethereum consensus based on a mobile terminal, and the method comprises the steps: allowing a smart phone and other mobile devices to participate in an Ethereum block verification process in a light node form and obtain rewards through reducing the technical threshold of a common user participating in a block chain consensus mechanism; according to the invention, the mobile terminal is connected with the verifier node in the Ethereum network; before each new block is generated, the verifier node serializes block data and historical state data and then sends the serialized block data and historical state data to the mobile terminal; after receiving the data, the mobile terminal executes lightweight Ethereum virtual machine verification, recalculates a state root and signs the state root; the server side collects a plurality of mobile terminal signatures, performs signature aggregation, embeds the aggregated signatures into a new block header, and broadcasts the aggregated signatures to the whole network; and after the other all nodes receive the block, the validity of the block is judged by verifying the number of the mobile terminals contained in the aggregation signature, so that the decentralized consensus is completed.

Description

Technical Field

[0001] The present invention belongs to the technical fields of blockchain technology and distributed system technology, and specifically relates to a verification method for light nodes participating in Ethereum consensus based on a mobile terminal. Background Art

[0002] Blockchain consensus mechanisms ensure that nodes in the network reach consensus on the blockchain's state. Ethereum currently primarily utilizes a proof-of-stake consensus mechanism, in which validator nodes must stake a certain amount of tokens to obtain the right to produce and validate blocks. However, due to device performance limitations and the cost of running a full node, ordinary users face difficulties in directly participating in consensus. This patent introduces mobile-based light nodes, enabling ordinary users to participate in block validation at a lower hardware cost. This enhances the decentralization of the consensus mechanism and improves network security and scalability.

[0003] Light nodes are a type of node that doesn't store the entire blockchain data, relying primarily on block headers provided by full nodes for verification. Light nodes can verify the correctness of blocks using state roots and Merkle proofs without downloading the entire blockchain history. This solution allows light nodes to perform BLS signatures after verifying blocks, enabling them to be more than just data consumers; they can also actively participate in consensus. Summary of the Invention

[0004] To address the issue of ordinary users being unable to participate in the Ethereum consensus mechanism at low cost, this paper proposes a mobile-based light node verification method for participating in the Ethereum consensus. This method utilizes light node technology, BLS signature aggregation, EVM execution, and state root verification to enable mobile devices to verify block data and participate in consensus without running a full node.

[0005] The technical solution adopted by the present invention is: a verification method for a mobile-based light node participating in the Ethereum consensus, comprising the following steps:

[0006] Step 1: The mobile terminal establishes a network connection with the validator node in the Ethereum network through the client application to participate in the block verification process;

[0007] Step 2: Before each new block generation round, the validator node serializes the packaged block data and the historical state data that the block depends on and sends them to the mobile terminal;

[0008] Step 3: The mobile terminal performs lightweight Ethereum virtual machine verification locally: executes transactions in the block based on historical state data and recalculates the state root value;

[0009] Step 4: When the transaction is executed correctly, the mobile terminal performs a BLS signature on the state root and returns the signature to the validator node;

[0010] Step 5: The validator node collects signatures from multiple mobile terminals, performs signature aggregation to generate an aggregate signature, and embeds the aggregate signature into the specified field of the new block header;

[0011] In step 6, the validator node broadcasts the new block containing the aggregate signature to the entire network. After receiving the block, other full nodes verify whether the number of mobile signatures contained in the aggregate signature meets the preset threshold and judge the validity of the block accordingly.

[0012] Furthermore, the client application includes:

[0013] The EVM execution verification module is used to run the EVM to calculate the transaction execution results and generate a new state root;

[0014] The BLS signature module is used to perform BLS signature on the new state root to ensure the security and aggregatability of the signature.

[0015] Furthermore, the verifier node includes:

[0016] The block data sending module is used to serialize and send the packaged block data and historical status data to the connected mobile terminal;

[0017] The signature collection and aggregation module is used to collect signatures from different mobile terminals and perform signature aggregation.

[0018] Furthermore, the full node includes:

[0019] The block synchronization verification module is used to check the correctness of the block and verify whether the number of signatures meets the consensus requirements, so as to determine whether to accept the block.

[0020] Furthermore, the specific steps of step 2 are:

[0021] In step 2-1, when the mobile terminal attempts to connect to the validator node, the node verifies whether the mobile terminal has staked the required tokens to qualify as a validator.

[0022] If the authentication is successful, the connection is established, the mobile terminal successfully subscribes to the subsequent block data, and proceeds to step 2-2;

[0023] If the identity authentication fails, the node returns an error and proceeds to steps 2-5;

[0024] Step 2-2: In the block generation phase, the validator node prepares the block data B to be verified. t and the status information S of the previous block t-1 , the node serializes these two parts of data: Serialized_B t =Serialize(Bt ), Serialized_S t-1 =Serialize(S t-1 ); Serialize means serializing the block data and status information into a JSON format that can be parsed by light nodes for easy parsing by mobile terminals;

[0025] In step 2-3, the validator node uses its private key to digitally sign the serialized data for verification by the mobile terminal after receiving the block data;

[0026] Step 2-4, the validator node will serialize the block data Serialized_B t Serialized state data Serialized_S t-1 And the digital signature is sent to all mobile devices that have successfully connected to the validator node;

[0027] Steps 2-5, end.

[0028] Furthermore, the specific steps of step 3 are:

[0029] Step 3-1, the mobile terminal receives the data packet (Serialized_B t ,Serialized_S t-1 ) and digital signature Signature, first use the verifier node public key to verify the signature;

[0030] If the verification is successful, proceed to step 3-2;

[0031] If verification fails, proceed to step 3-10;

[0032] Step 3-2, parse the data packet and restore it to block data and status information: B t =Deserialize(Serialized_B t ), S t-1 =Deserialize(Serialized_S t-1 ), where Deserialize converts it back into the original data, and the parsed data (B t , S t-1 ) for subsequent calculations;

[0033] Step 3-3, load and prepare the data required for EVM execution, create the EVM execution environment, including contract code C, block header data H, transaction data T and state data S; Among them, the contract code C stores all smart contract codes involved in the block C = HashCode1, HashCode2, ..., HashCode nIn the blockchain, each HashCode contains the hash value of a contract and the corresponding bytecode. During the block verification process, when the smart contract needs to be executed, the EVM can quickly find the corresponding bytecode through the hash value of the contract; the block header data H contains basic block information and state-related information, which is used to provide historical block queries when executing transactions and verify the continuity and legitimacy of the blocks; the transaction data T is a transaction list, which is the part that needs to be specifically verified; the state data S stores account state data and storage state data, which is used to read account data, storage data, and write data. It can provide the initial state before block execution, support state reading and writing during transaction execution, and is used to calculate the final state root hash;

[0034] Step 3-4, load the transaction list T in the block and prepare to execute the transaction: T = T1, T2, ..., T n, ; Each transaction T i Contains all transaction information; traverses the transaction list T to determine whether there are any unexecuted transactions;

[0035] If there are still transactions that have not been executed, proceed to steps 3-5;

[0036] If all transactions have been verified, proceed to steps 3-8.

[0037] Steps 3-5, for each transaction T i Conduct basic inspections;

[0038] If you pass the basic inspection, proceed to steps 3-6;

[0039] If the basic check fails, an error is returned and the process goes to step 3-10;

[0040] Steps 3-6: Execute transactions and apply each transaction to the state data.

[0041] Steps 3-7: Write the state changes of the account balance or contract storage to the state database and generate a transaction receipt. The impact of each transaction on the state is recorded as D i ; Record the state change information of all transactions for subsequent state root calculation; Return to steps 3-4;

[0042] Step 3-8: Verify that the Gas usage recorded in the block header is consistent with the actual Gas usage.

[0043] If the verification is consistent, proceed to step 3-9;

[0044] If the verification is inconsistent, an error is returned and the process goes to step 3-10;

[0045] Step 3-9, update status S t-1 ->S t, where S t =S t-1 +sum(D i );

[0046] Steps 3-10, end.

[0047] Furthermore, the specific steps of step 4 are:

[0048] Step 4-1: After the block is executed, the mobile terminal needs to calculate the state root of the block: Computed_S t =H(S t ); where H represents the generation of a new state root Computed_S t ;

[0049] Step 4-2, the mobile terminal is connected to Computed_S t Perform BLS signature: Sigma = Sign(Computed_S t ,SK); where Sigma is the mobile terminal’s signature on the state root, which will be submitted to the validator node for signature aggregation, and SK is the mobile terminal’s BLS private key;

[0050] Step 4-3, pack the signature data packet: (N, Computed_S t ,Sigma,Address,PK); where: N represents the block number; Computed_St represents the state root of the block, which is used to verify the state integrity; Sigma represents the BLS signature data of the block; Address represents the address of the verifier; PK represents the public key of the verifier, which is used to verify the signature;

[0051] Step 4-4: The mobile terminal sends the signature data packet to the signature collection and aggregation module of the verifier node for subsequent aggregation and verification;

[0052] Steps 4-5, end.

[0053] Furthermore, the specific steps of step 5 are:

[0054] Step 5-1: The validator node listens for signature data packets from different connected mobile terminals, and then attempts to encapsulate these signature data into blocks;

[0055] Step 5-2: The validator node verifies the legitimacy of the signature: checks whether the block number N is consistent with the current block number; checks whether the signer corresponding to the address Address has submitted a signature; and verifies whether the state root submitted by the mobile terminal matches the current state root.

[0056] If the verification is successful, proceed to step 5-3;

[0057] If the verification fails, an error is returned and the process goes to steps 5-7;

[0058] In step 5-3, the validator node stores all verified signatures and checks whether the number of collected signatures meets the minimum requirement;

[0059] If the requirements are met, proceed to step 5-4;

[0060] If the number of signatures is insufficient, an error is returned and steps 5-7 are performed;

[0061] In step 5-4, valid signatures are aggregated into an aggregate signature AggSign. At the same time, the verifier information including the address and public key is added to the Verifiers list, and then the final aggregate signature is obtained through the BLS aggregation algorithm.

[0062] In step 5-5, the validator node verifies the validity of the generated aggregate signature and checks whether the Verifiers list can verify the aggregate signature AggSign to ensure that the signatures corresponding to all public keys are for the same message;

[0063] If the verification is successful, proceed to step 5-6;

[0064] If the verification fails, an error is returned and the process goes to steps 5-7;

[0065] In steps 5-6, the validator node writes the aggregate signature AggSign and the validator information list Verifiers into the block header and block body respectively. The current validator node signs the block and writes the signature result into the block header to obtain the sealed block SealedBlock.

[0066] Steps 5-7, end.

[0067] Furthermore, the specific steps of step 6 are:

[0068] Step 6-1, verify the block header: including whether each field is correct and whether the signature meets the requirements of the consensus protocol; verify the block body: including whether the transaction root hash is correct and whether the parent block is correctly linked;

[0069] If the verification is successful, proceed to step 6-2;

[0070] If the verification fails, proceed to step 6-7;

[0071] Step 6-2: The full node maps the state root in the block header to the elliptic curve and generates a hash value H.

[0072] Step 6-3: The full node extracts the public key of each verifier in the verifier list and calculates the aggregate public key PK aggExtract the public key of each verifier from the Verifiers field and aggregate them.

[0073] In step 6-4, the full node uses the bilinear pairing algorithm to verify that the aggregate signature AggSign is a valid signature of the StateRoot by each verifier in the verifier list Verifiers;

[0074] If the verification is successful, proceed to step 6-5;

[0075] If the verification fails, proceed to step 6-7;

[0076] In step 6-5, the full node executes the transactions in the block, updates the blockchain state, verifies that the block state change is correct, re-executes all transactions in the block, and checks that the final state is consistent with the state root recorded in the block header.

[0077] If the verification is successful, proceed to step 6-6;

[0078] If the verification fails, proceed to step 6-7;

[0079] In step 6-6, the full node writes the block and its status to the database; stores the block data in the local blockchain database and updates the account status.

[0080] Steps 6-7, end.

[0081] The beneficial effects of the present invention are as follows: the present invention is different from the existing consensus mechanism that relies on the operation of full nodes, and is applicable to the field of decentralized consensus mechanism of blockchain; the present invention allows ordinary users to participate in block verification and consensus through light nodes on mobile phones. Users only need to run the light node App to participate in consensus, without the need for high-performance servers, which reduces the user's hardware and technical thresholds; at the same time, light nodes widely distributed on users' mobile phones around the world can improve the degree of decentralization. BRIEF DESCRIPTION OF THE DRAWINGS

[0082] Figure 1 It is a module relationship diagram of the present invention;

[0083] Figure 2 This is a flow chart of the block data sending module in the present invention;

[0084] Figure 3 This is a flow chart of the EVM execution verification module in the present invention;

[0085] Figure 4 This is the flow chart of the BLS signature module in the present invention;

[0086] Figure 5 This is a flow chart of the signature collection and aggregation module in the present invention;

[0087] Figure 6 This is a flow chart of the block synchronization verification module in the present invention;

[0088] Figure 7 This is a system deployment diagram of the present invention. DETAILED DESCRIPTION

[0089] In order to make the objectives, technical solutions and beneficial effects of the present invention clearer and more specific, the present invention is further described in detail below with reference to the accompanying drawings and specific examples. The described embodiments are specific descriptions of the preferred embodiments of the present invention, which are intended to help understand the present invention, but should not be used to limit the scope of protection of the present invention.

[0090] The present invention is a verification method for light nodes participating in the Ethereum consensus based on mobile terminals, which enables light node devices to participate in the Ethereum consensus mechanism without running full node programs. Figure 1 As shown, the present invention is to send the block verification task to the light node through the joint participation of the validator node on the server side and the client application installed on the mobile side, and the light node performs verification and signing, and feeds the signature back to the server for aggregation and broadcasting, thereby achieving light node consensus participation and obtaining rewards.

[0091] To achieve the above functions, the client application in the present invention includes an EVM execution verification module and a BLS signature module; the validator node includes a block data sending module and a signature collection and aggregation module, and the full node includes a block synchronization verification module.

[0092] The present invention comprises the following steps:

[0093] Step 1: The mobile terminal (smartphone, tablet or laptop) establishes a network connection with the validator node in the Ethereum network through the client application to participate in the block verification process, such as Figure 7 As shown;

[0094] Step 2: Before each new block is generated, the validator node packages the new block according to the Ethereum consensus mechanism, and serializes the packaged block data and the historical state data that the block depends on to the mobile terminal through the block data sending module; Figure 2 As shown, the specific steps are:

[0095] In step 2-1, when the mobile terminal attempts to connect to the validator node, the node verifies whether the mobile terminal has staked the required tokens to qualify as a validator.

[0096] If the authentication is successful, the connection is established, the mobile terminal successfully subscribes to the subsequent block data, and proceeds to step 2-2;

[0097] If the identity authentication fails, the node returns an error and proceeds to steps 2-5.

[0098] Step 2-2: In the block generation phase, the validator node prepares the block data B to be verified. t and the status information S of the previous block t-1 , the node serializes these two parts of data: Serialized_B t =Serialize(B t ), Serialized_S t-1 =Serialize(S t-1 ); Serialize means serializing the block data and status information into a JSON format that can be parsed by light nodes for easy parsing by mobile terminals.

[0099] In steps 2-3, the validator node uses its private key to digitally sign the serialized data for verification after the mobile terminal receives the block data.

[0100] Step 2-4, the validator node will serialize the block data Serialized_B t Serialized state data Serialized_S t-1 And the digital signature is sent to all mobile terminals that have successfully connected to the verifier node.

[0101] Steps 2-5, end.

[0102] Step 3: The mobile terminal executes the verification module through the EVM and performs lightweight Ethereum virtual machine verification locally: executes the transactions in the block based on the historical state data and recalculates the state root value; Figure 3 As shown, the specific steps are:

[0103] Step 3-1, the mobile terminal receives the data packet (Serialized_B t ,Serialized_S t-1 ) and digital signature Signature, first use the verifier node public key to verify the signature;

[0104] If the verification is successful, proceed to step 3-2;

[0105] If verification fails, proceed to step 3-10.

[0106] Step 3-2, parse the data packet and restore it to block data and status information: B t =Deserialize(Serialized_B t ), S t-1 =Deserialize(Serialized_S t-1), where Deserialize converts it back into the original data, and the parsed data (B t , S t-1 ) for subsequent calculations.

[0107] Step 3-3, load and prepare the data required for EVM execution, create the EVM execution environment, including contract code C, block header data H, transaction data T and state data S, etc.; Among them, the contract code C stores all the smart contract codes involved in the block C = HashCode1, HashCode2, ..., HashCode n In the blockchain, each HashCode contains the hash value of a contract and the corresponding bytecode. During the block verification process, when the smart contract needs to be executed, EVM can quickly find the corresponding bytecode through the hash value of the contract; the block header data H contains important information such as basic block information and state-related information, which is used to provide historical block queries when executing transactions and verify the continuity and legality of blocks; the transaction data T is a transaction list, which is the part that needs specific execution verification; the state data S stores account state data and storage state data, which is used to read account data, storage data, and write data. It can provide the initial state before block execution, support state reading and writing during transaction execution, and is used to calculate the final state root hash.

[0108] Step 3-4, load the transaction list T in the block and prepare to execute the transaction: T = T1, T2, ..., T n, ; Each transaction T i Contains all transaction information, such as sender, receiver, amount, fee, etc.; traverses the transaction list T to determine whether there are any unexecuted transactions;

[0109] If there are still transactions that have not been executed, proceed to steps 3-5;

[0110] If all transactions have been verified, proceed to steps 3-8.

[0111] Steps 3-5, for each transaction T i Perform basic checks such as transaction signature verification and account nonce verification;

[0112] If you pass the basic inspection, proceed to steps 3-6;

[0113] If the basic check fails, an error is returned and the process goes to step 3-10.

[0114] Steps 3-6: Execute transactions and apply each transaction to the state data.

[0115] Steps 3-7: Write the state changes such as account balance or contract storage to the state database and generate a transaction receipt. The impact of each transaction on the state is recorded as D i , for example: account balance decreases or increases, storage data changes, etc.; record the state change information of all transactions for subsequent state root calculation; return to steps 3-4.

[0116] Step 3-8: Verify that the Gas usage recorded in the block header is consistent with the actual Gas usage.

[0117] If the verification is consistent, proceed to step 3-9;

[0118] If the verification is inconsistent, an error is returned and the process goes to step 3-10.

[0119] Step 3-9, update status S t-1 ->S t , where S t =S t-1 +sum(D i ).

[0120] Steps 3-10, end.

[0121] Step 4: When the transaction is executed correctly, the mobile terminal uses the BLS signature module to sign the state root and returns the signature to the validator node; Figure 4 As shown, the specific steps are:

[0122] Step 4-1: After the block is executed, the mobile terminal needs to calculate the state root of the block: Computed_St = H(S t ); where H represents the generation of a new state root Computed_S t ;

[0123] Step 4-2, the mobile terminal is connected to Computed_S t Perform BLS signature: Sigma = Sign(Computed_S t ,SK); where Sigma is the mobile terminal’s signature on the state root, which will be submitted to the validator node for signature aggregation, and SK is the mobile terminal’s BLS private key;

[0124] Step 4-3, pack the signature data packet: (N, Computed_S t ,Sigma,Address,PK); where: N represents the block number; Computed_St represents the state root of the block, which is used to verify the state integrity; Sigma represents the BLS signature data of the block; Address represents the address of the verifier; PK represents the public key of the verifier, which is used to verify the signature;

[0125] Step 4-4: The mobile terminal sends the signature data packet to the signature collection and aggregation module of the verifier node for subsequent aggregation and verification;

[0126] Steps 4-5, end.

[0127] Step 5: The validator node collects signatures from multiple mobile terminals, executes the signature aggregation algorithm to generate an aggregate signature, and embeds the aggregate signature into the specified field of the new block header; Figure 5 As shown, the specific steps are:

[0128] In step 5-1, the validator node listens for signature data packets from different connected mobile terminals, and then tries to encapsulate these signature data into blocks.

[0129] Step 5-2: The validator node verifies the legitimacy of the signature: checks whether the block number N is consistent with the current block number; checks whether the signer corresponding to the address Address has submitted a signature; and verifies whether the state root submitted by the mobile terminal matches the current state root.

[0130] If the verification is successful, proceed to step 5-3;

[0131] If the verification fails, an error is returned and the process goes to steps 5-7.

[0132] In step 5-3, the validator node stores all verified signatures and checks whether the number of collected signatures meets the minimum requirement;

[0133] If the requirements are met, proceed to step 5-4;

[0134] If the number of signatures is insufficient, an error is returned and the process goes to steps 5-7.

[0135] In step 5-4, valid signatures are aggregated into an aggregate signature AggSign. At the same time, the verifier information including the address and public key is added to the Verifiers list, and then the final aggregate signature is obtained through the BLS aggregation algorithm.

[0136] In step 5-5, the validator node verifies the validity of the generated aggregate signature and checks whether the Verifiers list can verify the aggregate signature AggSign to ensure that the signatures corresponding to all public keys are for the same message;

[0137] If the verification is successful, proceed to step 5-6;

[0138] If the verification fails, an error is returned and the process goes to steps 5-7.

[0139] In steps 5-6, the validator node writes the aggregate signature AggSign and the verifier information list Verifiers into the block header and block body respectively, and the current validator node signs the block and writes the signature result into the block header to obtain the encapsulated block SealedBlock.

[0140] Steps 5-7, end.

[0141] Step 6: The validator node broadcasts the new block containing the aggregate signature to the entire network. After receiving the block, other full nodes verify the validity of the block to determine whether to accept the block; Figure 6 As shown, the specific steps are:

[0142] Step 6-1, verify the block header: including whether each field is correct and whether the signature meets the requirements of the consensus protocol; verify the block body: including whether the transaction root hash is correct and whether the parent block is correctly linked;

[0143] If the verification is successful, proceed to step 6-2;

[0144] If the verification fails, proceed to steps 6-7.

[0145] In step 6-2, the full node maps the state root in the block header to the elliptic curve and generates a hash value H = hash(StateRoot).

[0146] Step 6-3: The full node extracts the public key of each verifier in the verifier list and calculates the aggregate public key PK agg =PK1+PK2+...+PK n ; Extract the public key of each verifier from the Verifiers field and aggregate them.

[0147] In step 6-4, the full node uses the bilinear pairing algorithm to verify that the aggregate signature AggSign is a valid signature of each verifier in the verifier list Verifiers on StateRoot: e(AggSign,g2)=e(H,PK agg );

[0148] If the verification is successful, proceed to step 6-5;

[0149] If the verification fails, proceed to steps 6-7.

[0150] In step 6-5, the full node executes the transactions in the block, updates the blockchain state, verifies that the block state change is correct, re-executes all transactions in the block, and checks that the final state is consistent with the state root recorded in the block header.

[0151] If the verification is successful, proceed to step 6-6;

[0152] If the verification fails, proceed to steps 6-7.

[0153] In step 6-6, the full node writes the block and its status to the database; stores the block data in the local blockchain database and updates information such as account status.

[0154] Steps 6-7, end.

[0155] The following is an embodiment of the present invention, which is written in Go language.

[0156] Step 1: The mobile terminal (such as a smartphone) successfully establishes a network connection with the validator node in the Ethereum network through the client application, enabling the mobile terminal to participate in the subsequent block verification process.

[0157] Step 2: Before generating a new block, the validator node packages the new block according to the Ethereum consensus mechanism, serializes it with the historical state data, and sends it to the mobile terminal. The specific process is as follows:

[0158] In step 2-1, when the mobile terminal attempts to connect to the validator node, the node will verify whether the mobile terminal has pledged the required tokens to qualify as a validator. When the mobile terminal has pledged the corresponding amount of ETH, the identity verification is passed, the connection is successfully established, and the mobile terminal begins to subscribe to subsequent block data.

[0159] Step 2-2: In the block generation phase, the validator node prepares the block data B to be verified. t and the status information S of the previous block t-1 ; The prepared data is organized as shown in the following table:

[0160]

[0161]

[0162] The full data is as follows:

[0163]

[0164] The transactions data is as follows (T1):

[0165]

[0166] The snapshot data is as follows:

[0167]

[0168]

[0169] The item data is as follows (Item1):

[0170] Field Name value meaning Key account_balance_sender The key of the snapshot item, usually an account address or storage slot Value 1E+20 The value of the snapshot item, usually the account balance or storage data

[0171] The item data is as follows (Item2):

[0172] Field Name value meaning Key account_balance_recipient The key of the snapshot item, usually an account address or storage slot Value 0 The value of the snapshot item, usually the account balance or storage data

[0173] The header data is as follows (H1):

[0174]

[0175]

[0176] Rewards data is as follows (R1):

[0177] Field Name value meaning Address 0x6f397d9b31990201dad7675165d9d8d04f1f349b Reward recipient's address Amount 2.25458E+18 Reward Amount

[0178] The validator node serializes the above data and generates Serialized_B t and Serialized_S t-1 .

[0179] Step 2-3, the validator node uses its BLS private key to serialize the data (Serialized_B t and Serialized_S t-1 ) to digitally sign and generate a signature to ensure that the integrity and source of the data can be verified after the mobile terminal receives it.

[0180] Step 2-4, the validator node will serialize the block data Serialized_B t Serialized state data Serialized_S t-1 And the digital signature is sent to all mobile terminals that have successfully connected to the verifier node.

[0181] In step 3, the mobile terminal executes the verification module through the EVM, performs lightweight Ethereum virtual machine verification locally, executes transactions in the block based on historical state data, and recalculates the state root value. The specific process is as follows:

[0182] Step 3-1, the mobile terminal receives the data packet (Serialized_B t ,Serialized_S t-1 ) and digitally sign Signature, first use the public key of the verifier node to verify the signature; when the signature verification passes, proceed to the next step.

[0183] Step 3-2: The mobile terminal parses the data packet and restores it to the original block data B t and status information S t-1 , for subsequent calculations.

[0184] In step 3-3, the mobile terminal loads and prepares the data required for EVM execution and creates the EVM execution environment. This includes loading the contract code C (Codes), block header data H (Headers), transaction data T (Transactions), and state data S (Snap).

[0185] Step 3-4: The mobile terminal loads the transaction list T in the block and prepares to execute transactions; it traverses the transaction list T to determine whether there are any unexecuted transactions.

[0186] In this embodiment, the transaction list contains a transaction T1 that is not executed, and the process proceeds to the next step.

[0187] In steps 3-5, for transaction T1, check whether the sender's signature is valid and whether the nonce value is correct. Once these basic checks are complete, proceed to the next step.

[0188] In steps 3-6, execute transaction T1 and apply it to the state data. T1 is a transfer transaction that updates the account balance, etc. The updated changes are the list of items stored in the state data S.

[0189] The updated Items data is as follows (Item1):

[0190] Field Name value meaning Key account_balance_sender The key of the snapshot item, usually an account address or storage slot Value 9.89996E+19 The value of the snapshot item, usually the account balance or storage data

[0191] The updated Items data is as follows (Item2):

[0192] Field Name value meaning Key account_balance_recipient The key of the snapshot item, usually an account address or storage slot Value 1E+18 The value of the snapshot item, usually the account balance or storage data

[0193] In steps 3-7, the new account balance and other state changes are written to the state database, and a transaction receipt is generated for subsequent state root calculations. After traversing the transaction list T, if no other transactions have yet to be executed, proceed to the next step.

[0194] Step 3-8: Verify whether the Gas usage recorded in the block header is consistent with the actual Gas usage. If they are consistent, proceed to the next step.

[0195] Step 3-9, update the state, calculate the new state S based on the state changes caused by all transactions t .

[0196] Step 4: When the transaction is executed correctly, the mobile terminal uses the BLS signature module to sign the state root and returns the signature to the validator node. The specific process is as follows:

[0197] Step 4-1: After the block is executed, the mobile terminal needs to calculate the state root of the block. t Perform hash calculation to get Computed_S t , whose value is 0xc5d2460186f7233c927e7db2dcc703c0e500b653a33b7bfad8045d85a470.

[0198] Step 4-2, the mobile terminal is connected to Computed_S t Perform BLS signature. Use the mobile terminal's BLS private key SK to sign Computed_S t Sign and generate a signature Sigma, whose value is 0x8302b29936c3f050ff21fea02a251ca9bee864c60bc8a64c188234b1b08729e90b067d2953f5b7d88faf4476727e183b0efb8fd1eaea66f24f0954e0b1bf9e7a0220ab42abdbc33f206b12ad690d5ff193f53aaf9b0bf3f898b9437102aa4388.

[0199] Step 4-3: The mobile terminal packages the signature data packet as follows:

[0200]

[0201] Then, the signature data packet is serialized into JSON format for subsequent packaging and transmission.

[0202] In step 4-4, the mobile terminal sends the signature data packet to the signature collection and aggregation module of the validator node for subsequent aggregation and verification. The serialized signature data is encapsulated as a JSON-RPC request and sent to the validator node via a WebSocket connection.

[0203] In step 5, the validator node collects signatures from multiple mobile terminals, executes the signature aggregation algorithm to generate an aggregate signature, and embeds the aggregate signature into the specified field of the new block header. The specific process is as follows:

[0204] In step 5-1, the validator node listens for signature data packets from different connected mobile devices. It receives JSON-RPC requests from the mobile devices through the WebSocket interface, which contain signature data.

[0205] Step 5-2: The validator node verifies the legitimacy of the received signature. Check whether the block number N in the signature data packet is consistent with the current block number; check whether the signer corresponding to the address Address has submitted a signature to avoid duplicate signatures; verify the state root Computed_S submitted by the mobile terminal. t Check whether it matches the current state root. If verified, proceed to the next step.

[0206] In step 5-3, the validator node stores all verified signatures and checks whether the number of collected signatures meets the minimum requirement. If so, proceed to the next step.

[0207] Step 5-4: Aggregate valid signatures and aggregate multiple single signatures into an aggregate signature AggSign. Add all valid signatures to the aggrSigns list, and add the verifier information (address and public key) to the verifiers list, and then use the BLS aggregation algorithm to get the final aggregate signature 0xb1a2d3e4f5060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f202122232425262728292a2b2c2d2e2f303132333435363738393a3b3c3d3e3f404142434445464748494a4b4c4d4e4f505152535455565758595a5b5c5d5e5f.

[0208] In step 5-5, the validator node verifies the validity of the generated aggregate signature. The validator's public key byte array is converted into a BLS public key object, and the aggregate signature byte array is converted into a BLS signature object. The fast aggregate verification algorithm is then used to verify that the aggregate signature AggSign can be verified by all public keys in the Verifiers list, ensuring that the signatures corresponding to all public keys are for the same message (i.e., the state root). If verification is successful, proceed to the next step.

[0209] In steps 5-6, the validator node writes the aggregate signature AggSign and the verifier information list Verifiers into the block header and block body respectively, and the current validator node signs the block and writes the signature result into the block header to obtain the encapsulated block SealedBlock.

[0210] In step 6, the validator node broadcasts the new block containing the aggregate signature to the entire network. After receiving the block, other full nodes verify the validity of the block to determine whether to accept the block. The specific process is as follows:

[0211] In step 6-1, after receiving a block, the full node first verifies the block header and block body. It checks that the various fields in the block header are correct and that the signature meets the requirements of the consensus protocol. It also verifies that the transaction root hash in the block body is correct and that the parent block is correctly linked. If verification passes, proceed to the next step.

[0212] In step 6-2, the full node maps the state root StateRoot recorded in the block header to the elliptic curve and generates a hash value H.

[0213] In step 6-3, the full node extracts the public key of each verifier in the verifier list Verifiers and calculates the aggregate public key PKagg; extracts the public key of each verifier from the Verifiers field and aggregates them.

[0214] In step 6-4, the full node uses a bilinear pairing algorithm to verify that the aggregate signature AggSign is a valid signature of the StateRoot by each verifier in the Verifiers list. This is verified using the formula e(AggSign, g2) = e(H, PKagg). If verification passes, proceed to the next step.

[0215] In step 6-5, the full node executes the transactions in the block, updates the blockchain state, verifies that the block state change is correct, re-executes all transactions in the block, and checks that the final state is consistent with the state root recorded in the block header. If verification passes, proceed to the next step.

[0216] In step 6-6, the full node writes the block and its status to the database; stores the block data in the local blockchain database and updates information such as account status.

Claims

1. A verification method for a mobile-based light node participating in the Ethereum consensus, characterized in that: The following steps are involved: Step 1: The mobile terminal establishes a network connection with the validator node in the Ethereum network through the client application to participate in the block verification process; Step 2: Before each new block generation round, the validator node serializes the packaged block data and the historical state data that the block depends on and sends them to the mobile terminal; Step 3: The mobile terminal performs lightweight Ethereum virtual machine verification locally: executes transactions in the block based on historical state data and recalculates the state root value; Step 4: When the transaction is executed correctly, the mobile terminal performs a BLS signature on the state root and returns the signature to the validator node; Step 5: The validator node collects signatures from multiple mobile terminals, performs signature aggregation to generate an aggregate signature, and embeds the aggregate signature into the specified field of the new block header; In step 6, the validator node broadcasts the new block containing the aggregate signature to the entire network. After receiving the block, other full nodes verify whether the number of mobile signatures contained in the aggregate signature meets the preset threshold and judge the validity of the block accordingly.

2. A verification method for a mobile-based light node participating in the Ethereum consensus according to claim 1, characterized in that: The client application includes: The EVM execution verification module is used to run the EVM to calculate the transaction execution results and generate a new state root; The BLS signature module is used to perform BLS signature on the new state root to ensure the security and aggregatability of the signature.

3. A verification method for a mobile-based light node participating in the Ethereum consensus according to claim 1, characterized in that: The validator node includes: The block data sending module is used to serialize and send the packaged block data and historical status data to the connected mobile terminal; The signature collection and aggregation module is used to collect signatures from different mobile terminals and perform signature aggregation.

4. A method for participating in the Ethereum consensus mechanism based on a mobile light node according to claim 1, characterized in that: The full node includes: The block synchronization verification module is used to check the correctness of the block and verify whether the number of signatures meets the consensus requirements, so as to determine whether to accept the block.

5. A verification method for a mobile-based light node participating in the Ethereum consensus according to claim 1, characterized in that: The specific steps of step 2 are: In step 2-1, when the mobile terminal attempts to connect to the validator node, the node verifies whether the mobile terminal has staked the required tokens to qualify as a validator. If the authentication is successful, the connection is established, the mobile terminal successfully subscribes to the subsequent block data, and proceeds to step 2-2; If the identity authentication fails, the node returns an error and proceeds to steps 2-5; Step 2-2: In the block generation phase, the validator node prepares the block data B to be verified. t and the status information S of the previous block t-1 , the node serializes these two parts of data: Serialized_B t =Serialize(B t ), Serialized_S t-1 =Serialize(S t-1 ); Serialize means serializing the block data and status information into a JSON format that can be parsed by light nodes for easy parsing by mobile terminals; In step 2-3, the validator node uses its private key to digitally sign the serialized data for verification by the mobile terminal after receiving the block data; Step 2-4, the validator node will serialize the block data Serialized_B t Serialized state data Serialized_S t-1 And the digital signature is sent to all mobile devices that have successfully connected to the validator node; Steps 2-5, end.

6. A verification method for a mobile-based light node participating in the Ethereum consensus according to claim 1, characterized in that: The specific steps of step 3 are: Step 3-1, the mobile terminal receives the data packet (Serialized_B t ,Serialized_S t-1 ) and digital signature Signature, first use the verifier node public key to verify the signature; If the verification is successful, proceed to step 3-2; If verification fails, proceed to step 3-10; Step 3-2, parse the data packet and restore it to block data and status information: B t =Deserialize(Serialized_B t ), S t-1 =Deserialize(Serialized_S t-1 ), where Deserialize converts it back into the original data, and the parsed data (B t , S t-1 ) for subsequent calculations; Step 3-3, load and prepare the data required for EVM execution, create the EVM execution environment, including contract code C, block header data H, transaction data T and state data S; Among them, the contract code C stores all smart contract codes involved in the block C = HashCode1, HashCode2, ..., HashCode n In the blockchain, each HashCode contains the hash value of a contract and the corresponding bytecode. During the block verification process, when the smart contract needs to be executed, the EVM can quickly find the corresponding bytecode through the hash value of the contract; the block header data H contains basic block information and state-related information, which is used to provide historical block queries when executing transactions and verify the continuity and legitimacy of the blocks; the transaction data T is a transaction list, which is the part that needs to be specifically verified; the state data S stores account state data and storage state data, which is used to read account data, storage data, and write data. It can provide the initial state before block execution, support state reading and writing during transaction execution, and is used to calculate the final state root hash; Step 3-4, load the transaction list T in the block and prepare to execute the transaction: T = T1, T2, ..., T n, ; Each transaction T i Contains all transaction information; traverses the transaction list T to determine whether there are any unexecuted transactions; If there are still transactions that have not been executed, proceed to steps 3-5; If all transactions have been verified, proceed to steps 3-8. Steps 3-5, for each transaction T i Conduct basic inspections; If you pass the basic inspection, proceed to steps 3-6; If the basic check fails, an error is returned and the process goes to step 3-10; Steps 3-6: Execute transactions and apply each transaction to the state data. Steps 3-7: Write the state changes of the account balance or contract storage to the state database and generate a transaction receipt. The impact of each transaction on the state is recorded as D i ; Record the state change information of all transactions for subsequent state root calculation; Return to steps 3-4; Step 3-8: Verify that the Gas usage recorded in the block header is consistent with the actual Gas usage. If the verification is consistent, proceed to step 3-9; If the verification is inconsistent, an error is returned and the process goes to step 3-10; Step 3-9, update status S t-1 ->S t , where S t =S t-1 +sum(D i ); Steps 3-10, end.

7. A verification method for a mobile-based light node participating in the Ethereum consensus according to claim 1, characterized in that: The specific steps of step 4 are: Step 4-1: After the block is executed, the mobile terminal needs to calculate the state root of the block: Computed_S t =H(S t ); where H represents the generation of a new state root Computed_S t ; Step 4-2, the mobile terminal is connected to Computed_S t Perform BLS signature: Sigma = Sign(Computed_S t ,SK); where Sigma is the mobile terminal’s signature on the state root, which will be submitted to the validator node for signature aggregation, and SK is the mobile terminal’s BLS private key; Step 4-3, pack the signature data packet: (N, Computed_S t ,Sigma,Address,PK); where: N represents the block number; Computed_S t Represents the state root of the block, used to verify state integrity; Sigma represents the BLS signature data of the block; Address represents the address of the validator; PK represents the public key of the validator, used to verify the signature; Step 4-4: The mobile terminal sends the signature data packet to the signature collection and aggregation module of the verifier node for subsequent aggregation and verification; Steps 4-5, end.

8. A verification method for a mobile-based light node participating in the Ethereum consensus according to claim 1, characterized in that: The specific steps of step 5 are: Step 5-1: The validator node listens for signature data packets from different connected mobile terminals, and then attempts to encapsulate these signature data into blocks; Step 5-2: The validator node verifies the legitimacy of the signature by checking whether the block number N is consistent with the current block number; Check whether the signer corresponding to the address has submitted a signature; verify whether the state root submitted by the mobile terminal matches the current state root; If the verification is successful, proceed to step 5-3; If the verification fails, an error is returned and the process goes to steps 5-7; In step 5-3, the validator node stores all verified signatures and checks whether the number of collected signatures meets the minimum requirement; If the requirements are met, proceed to step 5-4; If the number of signatures is insufficient, an error is returned and steps 5-7 are performed; In step 5-4, valid signatures are aggregated into an aggregate signature AggSign. At the same time, the verifier information including the address and public key is added to the Verifiers list, and then the final aggregate signature is obtained through the BLS aggregation algorithm. In step 5-5, the validator node verifies the validity of the generated aggregate signature and checks whether the Verifiers list can verify the aggregate signature AggSign to ensure that the signatures corresponding to all public keys are for the same message; If the verification is successful, proceed to step 5-6; If the verification fails, an error is returned and the process goes to steps 5-7; In steps 5-6, the validator node writes the aggregate signature AggSign and the validator information list Verifiers into the block header and block body respectively. The current validator node signs the block and writes the signature result into the block header to obtain the sealed block SealedBlock. Steps 5-7, end.

9. A verification method for a mobile-based light node participating in the Ethereum consensus according to claim 1, characterized in that: The specific steps of step 6 are: Step 6-1, verify the block header: including whether each field is correct and whether the signature meets the requirements of the consensus protocol; verify the block body: including whether the transaction root hash is correct and whether the parent block is correctly linked; If the verification is successful, proceed to step 6-2; If the verification fails, proceed to step 6-7; Step 6-2: The full node maps the state root in the block header to the elliptic curve and generates a hash value H. Step 6-3: The full node extracts the public key of each verifier in the verifier list and calculates the aggregate public key PK agg Extract the public key of each verifier from the Verifiers field and aggregate them. In step 6-4, the full node uses the bilinear pairing algorithm to verify that the aggregate signature AggSign is a valid signature of the StateRoot by each verifier in the verifier list Verifiers; If the verification is successful, proceed to step 6-5; If the verification fails, proceed to step 6-7; In step 6-5, the full node executes the transactions in the block, updates the blockchain state, verifies that the block state change is correct, re-executes all transactions in the block, and checks that the final state is consistent with the state root recorded in the block header. If the verification is successful, proceed to step 6-6; If the verification fails, proceed to step 6-7; In step 6-6, the full node writes the block and its status to the database; stores the block data in the local blockchain database and updates the account status. Steps 6-7, end.

Images