일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 | 31 |
- multicall
- 컨트렉트 배포 자동화
- 컨트렉트 동일한 함수이름 호출
- 체인의정석
- 스마트컨트렉트프록시
- 스마트컨트렉트테스트
- SBT표준
- 스마트컨트렉트 예약어 함수이름 중복
- 스마트컨트렉트 함수이름 중복 호출
- Vue.js
- Vue
- vue기초
- ethers type
- ethers typescript
- ethers v6
- 티스토리챌린지
- rust 기초
- ethers websocket
- 프록시배포구조
- ethers
- 러스트 기초 학습
- 스마트 컨트렉트 함수이름 중복
- 러스트 기초
- 오블완
- 머신러닝기초
- 러스트기초
- git rebase
- chainlink 설명
- nest.js설명
- ambiguous function description
- Today
- Total
체인의정석
스마트컨트렉트, 서로 다른 체인에서 같은 컨트렉트 주소가 나올 수 있을까? 본문
서로 다른 체인에서 같은 컨트렉트 주소가 나올 수 있을까?
현재 작성하는 프로그램에서 서로 다른 체인에서 상호작용을 하는데 CA를 키값으로 매핑을 구현하였다.
어차피 중간에 있는 관리 프로그램이 관리를 할 예정이지만 충분히 고려해봐야 할 상황이기 때문에 조사를 해보았다.
일단, 결론부터 말하자면 지갑과 nonce값이 같다면 같은 값이 나올 수 있다는것이 정답이다. 따라서 CA를 여러 다른 체인에서 같이 다룰때는 이를 고려하여 코드를 짜야한다.
https://www.reddit.com/r/ethdev/comments/nxcc6r/how_can_contracts_have_the_same_addresses_across/
위의 글에서 볼 수 있었는데
const RLP = require('rlp')
function contractAddr(sender, nonce) {
var input_arr = [ sender, nonce ];
var rlp_encoded = RLP.encode(input_arr)
var contract_address_long = keccak('keccak256').update(rlp_encoded).digest('hex');
return contract_address_long.substring(24); //Trim the first 24 characters.
}
let nonce = await web3.eth.getTransactionCount(accounts[0], 'pending')
nonce = nonce + 1
let contractFutureAddress = contractAddr(
accounts[0],
nonce
)
console.log('future', contractFutureAddress)
위와 같이 보내는 사람의 공개키와 nonce를 가지고 있으면 나중에 해당 주소로 부터 나오는 컨트렉트 주소를 알 수 있다고 한다.
There are two different ways contract addresses can be determined.
Contracts created with the CREATE opcode or created directly with a transaction will have an address that is a hash of the deployer's address and the deployer's nonce. So long as you control the deployed and use it for very limited purposes, you can ensure that the same deployer uses the same nonce to deploy on each chain.
Contracts created by the CREATE2 opcode will have an address determined by the deployed address, the contract code, and a seed chosen by the contract. This requires a contract deployed with CREATE at some predictable address, but then you could use that to deploy loads of contracts with predictable addresses to different chains.
이는 어떤 CREATE opcode가 호출되는지에 따라서 갈린다고 하는데 CREATE2 opcode에서는 계산방법이 다르다고 한다.
다른 글을 찾아보니 그 차이점을 명확히 알 수 있었다.
1. CREATE opcode : 기본적으로 배포하는 경우
keccak256(senderAddress, nonce)
2. CREATE2 opcode : 스마트컨트렉트 내부에서 배포를 하는 경우
keccak256(0xFF, senderAddress, salt, bytecode)
2번의 경우 미리 컨트렉트 주소를 정해서 배포할 수 있다.
2번의 예시는 아래에서 찾을 수 있다.
https://github.com/miguelmota/solidity-create2-example
결론은 ca 충돌이 가능하기 때문에 이를 고려해서 프로그램을 짜야된다는 점이다. 이를 어떻게 풀어낼지는 다시 고민해봐야겠다.