How Does qMig work?

Step 1:

The qMig approach is illustrated with a timeline shown in figure 3. The blue phase represents a time period when quantum attacks on ECDSA are still not feasible. In this period, the qMig contract enables users to construct and record a future intent to transfer tokens, in case the quantum inflection point occurs and ECDSA signature by itself can not be trusted. The security of this intent will be rooted in cryptography that is not susceptible to quantum attacks. Figure 4 below, illustrates how this works. To call qMig.registerTransferIntent(), the client creates a transfer intent source structure that includes source EOA (‘from’ field), the chain ID for this EOA and its future destination counterpart. So for example, the source address 0x1739…3c75, may own USDC (ERC20 token) on chain ID 1 (Ethereum mainnet). An updated bridge contract (e.g., LayerZero), will be able to utilise this information, to verify that the destination address was authorised by 0x1739…3c75, prior to the inflection point.

As shown in figure 4, the client must sign the transfer intent source with the ECDSA private key that corresponds to the EOA source address in the structure (this linkage is verified at a later stage, if transfer is initiated in step 3 of figure 3).

Figure 4: Generating Incognito Transfer Intent. (This image was generated with the Eth.build tool).

The signed output is fed into Keccak-256 hash function, the resulting digest is referred to as incognito transfer intent in the above figure. This digest is stored in a hash table by registerTransferIntent() method along with the corresponding block height (e.g., 16316192) , preserving a record on the blockchain of when the intent was registered.

Please note:

• The hash of the signature rather than the signature itself is persisted so that a public key of EOA can not be extracted. Moreover the wallet address used to sign the request for calling registerTransferIntent() is recommended to be different from the source EOA, to avoid leaving a record of the ECDSA public key.

• The Keccak-256 function is assumed to be resilient to finding collisions based on quantum hardware.

After the inflection point, the recorded block height along with the hash over the signature will serve as proof that source EOA authorised the transfer to the target destination address and not the attacker’s address. The ledger record shows that this was captured, prior to the quantum breakthrough when the attacker could derive the ECDSA private key.

Step 2:

ECDSA is compromised (the quantum inflection point of figure 3). For every token contract prepared for this scenario, its token administrator sets the block height in the bridge contract, representing a point when quantum computing attacks on ECDSA are effective. If this value is set, a new authorization policy takes effect for all further transfer of assets over the bridge to a quantum safe network. It is described in step 3. Note that the bridge contract's administrative functionality should be protected by a secondary, quantum resilient signature (e.g., CRYSTALS-Dilithium).

Step 3:

Represented as the red phase in figure 3. In this phase, users can transfer tokens to a quantum resilient blockchain, subject to the following restrictions. To prevent stolen funds from being transferred, the bridge contract permits transfer if two conditions are met:

1. The destination address was authorised by the source address from step 1. That is, at some point prior to the inflection point, the user needs to call registerTransferIntent(). The bridge contract can verify this by calling the verifyTransferIntent() method exposed by the qMig contract. To achieve this, the client will build and sign the transfer intent source (shown in figure 5 below, and then will pass the raw signature (transfer intent sig) in conjunction with the transfer request to the bridge contract. The bridge contract calls verifyTransferIntent(), passing the source & destination info, the raw signature (transfer intent sig) as well as the blockchain height value (the inflection point set in step 2). verifyTransferIntent() performs verification through a process shown in Figure 5. It uses the public key from the transfer intent sig to cryptographically verify the signed data and confirm the signer’s address matches the source address in the transfer intent source structure, thus confirming that it was the source that authorised the destination address. Next, is the look up to check that the qMig contract has a record of the target intent. Just like in step 1, the transfer intent sig is passed to Keccak-256, to compute the incognito transfer intent digest. This value is then looked up in a hash table of all recorded transfer intents. If found, the returned block height must be less than the block height passed in by the bridge contract:

require (intentBlockHeight < inflectionPointBlockHeight, “Intent to transfer registered after the quantum inflection point!”)

Figure 5: Verifying Incognito Transfer Intent (This image was generated with the Eth.build tool).

2. The next key requirement to address is that this mechanism must prevent any potentially stolen assets (due to ECDSA compromise) from being bridged to the quantum-safe blockchain. The source address in the transfer intent could have funds obtained illicitly from others via ECDSA compromise, sometime after quantum inflection point. To address this, the amount permitted to transfer for a given source address is the balance at quantum inflection point (block height set in step 2), subtract from the sum total of all withdraws since that block number (up to the most recent block). The above can be augmented to allow for transfers from addresses that were explicitly authorised by the destination addresses to source address prior to the inflection point (using the same mechanism).