배포 전 스마트 계약의 주소를 결정하는 방법: 암호화폐 교환을 위해 CREATE2 사용

블록체인이라는 주제는 온갖 종류의 과대광고뿐만 아니라 기술적 관점에서 매우 가치 있는 아이디어의 원천이기도 합니다. 따라서 그녀는 햇볕이 잘 드는 도시의 주민들을 우회하지 않았습니다. 사람들은 전통적인 정보 베이스에 대한 전문 지식을 블록체인 시스템으로 전환하기 위해 면밀히 살펴보고, 연구하고, 노력하고 있습니다. 지금까지 Rostelecom-Solar의 개발 중 하나는 블록체인을 기반으로 소프트웨어의 보안을 확인할 수 있다는 점입니다. 그리고 그 과정에서 블록체인 커뮤니티의 응용 문제를 해결하는 데 대한 몇 가지 생각이 떠오릅니다. 이러한 생활 해킹 중 하나인 CREATE2를 사용하여 배포하기 전에 스마트 계약의 주소를 결정하는 방법을 오늘 여러분과 공유하고 싶습니다.

CREATE2 opcode는 올해 28월 XNUMX일 콘스탄티노플 하드 포크에 추가되었습니다. EIP에 명시된 대로 이 opcode는 주로 상태 채널에 도입되었습니다. 그러나 우리는 이를 다른 문제를 해결하는 데 사용했습니다.

거래소에 잔액이 있는 사용자가 있습니다. 우리는 각 사용자에게 누구나 토큰을 보낼 수 있는 이더리움 주소를 제공하여 계정을 보충해야 합니다. 이 주소를 "지갑"이라고 부르겠습니다. 토큰이 지갑에 도착하면 이를 단일 지갑(hotwallet)으로 보내야 합니다.

다음 섹션에서는 CREATE2 없이 이 문제를 해결하기 위한 옵션을 분석하고 왜 이를 포기했는지 설명합니다. 최종 결과에만 관심이 있는 경우 최종 솔루션 섹션에서 찾을 수 있습니다.

이더리움 주소

가장 간단한 해결책은 신규 사용자를 위해 새로운 이더리움 주소를 생성하는 것입니다. 이 주소가 지갑이 됩니다. 지갑에서 핫월렛으로 토큰을 전송하려면 함수를 호출하여 거래에 서명해야 합니다. 이전() 백엔드에서 지갑의 개인 키를 사용합니다.

이 접근 방식에는 다음과 같은 장점이 있습니다.

• 그냥
• 지갑에서 핫월렛으로 토큰을 전송하는 비용은 함수를 호출하는 비용과 같습니다. 이전()

그러나 우리는 이 접근 방식에 한 가지 중요한 단점이 있기 때문에 포기했습니다. 즉, 개인 키를 어딘가에 저장해야 한다는 것입니다. 그리고 이러한 키는 분실될 수 있을 뿐만 아니라 이러한 키에 대한 액세스를 신중하게 관리해야 합니다. 그 중 적어도 하나가 손상되면 특정 사용자의 토큰이 핫 지갑에 도달하지 않습니다.

각 사용자에 대해 별도의 스마트 계약 생성

각 사용자마다 별도의 스마트 계약을 배포하면 지갑의 개인 키를 서버에 저장할 수 없습니다. 거래소는 이 스마트 계약을 호출하여 토큰을 핫월렛으로 전송합니다.

또한 스마트 계약을 배포하지 않으면 사용자에게 자신의 지갑 주소를 표시할 수 없기 때문에 이 솔루션을 포기했습니다(실제로는 가능하지만 여기서 논의하지 않는 다른 단점이 있어 다소 복잡한 방식입니다). 거래소에서 사용자는 필요한 만큼 많은 계정을 만들 수 있으며 모든 사람은 자신의 지갑이 필요합니다. 이는 사용자가 이 계정을 사용할 것이라는 확신 없이 계약을 배포하려면 돈을 써야 한다는 것을 의미합니다.

Op코드 CREATE2

이전 방법의 문제를 해결하기 위해 CREATE2 opcode를 사용하기로 결정했습니다. CREATE2를 사용하면 스마트 계약이 배포될 주소를 미리 결정할 수 있습니다. 주소는 다음 공식을 사용하여 계산됩니다.

keccak256 (0xff ++ address ++ salt ++ keccak256 (init_code)) [12:]

, 여기서 :

• 주소 — CREATE2를 호출할 스마트 계약의 주소
• 소금 - 임의의 값
• 초기화_코드 - 배포용 스마트 계약 바이트코드

이렇게 하면 우리가 사용자에게 제공하는 주소에 실제로 원하는 바이트코드가 포함됩니다. 또한 이 스마트 계약은 필요할 때마다 배포할 수 있습니다. 예를 들어, 사용자가 처음으로 지갑을 사용하기로 결정한 경우입니다.

또한 다음과 같은 이유로 스마트 계약 주소를 저장하는 대신 매번 계산할 수 있습니다.

• 주소 공식은 우리 지갑 공장의 주소이므로 상수입니다.
• 소금 - user_id 해시
• 초기화_코드 동일한 지갑을 사용하기 때문에 영구적입니다.

추가 개선

이전 솔루션에는 여전히 한 가지 단점이 있습니다. 즉, 스마트 계약 배포 비용을 지불해야 한다는 것입니다. 그러나 제거할 수 있습니다. 이를 위해 함수를 호출할 수 있습니다. 이전()그런 다음 자폭() 지갑 생성자에서. 그런 다음 스마트 계약을 배포하기 위한 가스가 반환됩니다.

일반적인 믿음과는 달리 CREATE2 opcode를 사용하면 동일한 주소에 스마트 계약을 여러 번 배포할 수 있습니다. 이는 CREATE2가 대상 주소의 nonce가 1인지 확인하기 때문입니다(생성자 시작 부분에 값 "XNUMX"이 할당됨). 동시에, 기능 자폭() 매번 Nonce 주소를 재설정합니다. 따라서 동일한 인수를 사용하여 CREATE2를 다시 호출하면 nonce 검사가 통과됩니다.

이 솔루션은 이더리움 주소 솔루션과 유사하지만 개인 키를 저장할 필요가 없다는 점에 유의하세요. 지갑에서 핫월렛으로 돈을 이체하는 비용은 함수를 호출하는 비용과 거의 같습니다. 이전(), 왜냐하면 우리는 스마트 계약 배포 비용을 지불하지 않기 때문입니다.

최종 결정

처음에 준비한 것:

• 소금을 얻는 기능 USER_ID
• 적절한 솔트(예: 지갑 팩토리)를 사용하여 CREATE2 opcode를 호출하는 스마트 계약
• 다음 생성자와의 계약에 해당하는 지갑 바이트코드:

constructor () {
    address hotWallet = 0x…;
    address token = 0x…;
    token.transfer (hotWallet, token.balanceOf (address (this)));
    selfdestruct (address (0));
}

각각의 신규 사용자에 대해 우리는 계산을 통해 지갑 주소를 표시합니다.

keccak256 (0xff ++ address ++ salt ++ keccak256 (init_code)) [12:]

사용자가 해당 지갑 주소로 토큰을 전송하면 백엔드에서 매개변수가 포함된 전송 이벤트를 확인합니다. _에게지갑 주소와 동일합니다. 이 시점에서는 지갑을 배포하기 전에 이미 거래소에서 사용자의 잔액을 늘리는 것이 가능합니다.

지갑 주소에 충분한 토큰이 쌓이면 한꺼번에 핫월렛으로 전송할 수 있습니다. 이를 위해 백엔드는 다음 작업을 수행하는 스마트 계약 팩토리 함수를 호출합니다.

function deployWallet (соль uint256) {
    bytes memory walletBytecode =…;
    // invoke CREATE2 with wallet bytecode and salt
}

따라서 지갑 스마트 계약 생성자가 호출되어 모든 토큰을 핫월렛 주소로 전송한 다음 자체 소멸됩니다.

전체 코드를 찾을 수 있습니다 여기에. 우리는 지갑 바이트코드를 최적화하고 이를 opcode로 작성하기로 결정했기 때문에 이것은 우리의 생산 코드가 아니라는 점에 유의하십시오.

저자 Pavel Kondratenkov, 이더리움 전문가

출처 : habr.com