Post-Quantum Proxy Contract Pattern

srarcharles · June 29, 2024, 1:44am

I want you all to check out my idea.
New “Proxy Pattern Smart Contract with Quantum-Resistance Ability”

I’m concerning about quantum-computer’s attacks on Proxy contract. It may become single point of failure(SPOF) for many smart contract(DApps like LIDO, DEFIs, etc…) because malicious quantum attacker can upgrade proxy’s embedded address to any address they want without users knowing it have happened.

About commonly used “Proxy Pattern”
Proxy Upgrade Pattern - OpenZeppelin Docs

But, I find out new smart contract to protect it to be attacked when secret keys of smart contract owner of proxy contract is stollen.

Above is new scheme of smart contract with ability to prevent the attack to Proxy contract.

Main Point is…

Proxy contract’s implementation addresses can only be upgraded through the authentication by post-quantum signature scheme(like Lamport Signature).

So, malicious attacker can not upgrade Proxy contracts’ implementation addresses with Alice(Owner)'s secret key.

I also have written minimum implementation with tests of this idea although authentication part is not implemented(because any Post-quantum signature scheme can be embedded there like Pauli Group’s Lamport Signature Authentication)

This repository includes minimum implementation of quantum-resistant proxy contract. (I called it ProxyWallet)

github.com

starcharles/quantum-resistant-proxy-contract/blob/main/test/ProxyWallet.spec.ts

import {
  time,
  loadFixture,
} from "@nomicfoundation/hardhat-toolbox-viem/network-helpers";
import { expect } from "chai";
import hre from "hardhat";
import "@nomicfoundation/hardhat-ethers";
import {
  getAddress,
  keccak256,
  Abi,
  parseGwei,
  getContract,
  TransactionExecutionError,
} from "viem";
import { AbiCoder } from "ethers";

describe("ProxyWallet contract", function () {
  async function deployFixture() {
    const [owner, addr1, addr2] = await hre.viem.getWalletClients();

This file has been truncated. show original

This includes

Contract code to realize my concept.
Tests to confirm desirable behavior of the contract.

Please feel free to give me any comments and further implovement idea.
And If this idea make sense or valuable for Ethereum Community, I want to propose this as new ERC.

Thanks for reading.

Naoto Sato (Blocq, Inc)