공개 mempool에 들어간 거래는 아직 block이 아닙니다. 그 거래를 누가 어떤 순서로 묶는지가 한 칸의 가치가 됩니다. ethereum.org는 그 가치를 Maximal extractable value, MEV라고 부릅니다. 이전 글에서 RPC 잔액이 node마다 다름을 봤습니다. 이번에는 같은 체인 안에서, 아직 확정되지 않은 거래 목록을 ...
탐색기 한 칸의 balance는 그 사이트가 고른 node의 답입니다. 같은 address를 다른 RPC에 물으면 숫자가 갈라집니다. 브리지가 그 숫자 하나를 다른 체인에 mint하면, 옮기는 것은 자산이 아니라 그 node를 믿겠다는 결정입니다. 이전 글에서 sequencer RPC의 confirmation이 L1 finalized가 아님을 봤습니...
L2 explorer의 confirmation 1은 L1의 finalized가 아닙니다. 거래를 받은 쪽이 sequencer이고, 그 결과를 Ethereum에 올리는 쪽이 batch이며, 정착 시계는 L1 합의입니다. 이전 글에서 공개 니모닉을 운영키로 쓰지 않는 이유를 봤습니다. 이번에는 그 키가 붙는 RPC가 한 체인이 아닐 수 있음을 봅니다. ...
Anvil을 켜면 계정 0의 address는 항상 0xf39Fd6e5...입니다. 그 값은 마법이 아닙니다. Foundry가 문서에 적어 둔 12단어 니모닉의 인덱스 0입니다. 그 문구를 아는 사람은 같은 개인키를 다시 계산할 수 있습니다. 이전 글에서 머리가 갈라지거나 멈추는 모양을 봤습니다. 이번에는 그 머리에 서명을 넣는 키를 로컬에서만 다룹니...
indexer가 confirmations >= 1을 보면 입금을 끝낸 것처럼 움직입니다. 같은 숫자를 Bitcoin node와 Ethereum node에 물으면, 돌아오는 객체가 다릅니다. 하나는 지금 활성 팁까지의 깊이이고, 다른 하나는 checkpoint 투표가 만든 finalized 높이입니다. 이전 글에서 권한과 event로 이더를 잠갔...
숫자를 올리는 Counter와 달리, Escrow는 이더를 잠급니다. 누가 deposit을 호출할 수 있는지, 누가 release를 호출할 수 있는지가 곧 돈의 경로입니다. 이전 글에서 HTTP 200이 chain head가 아님을 확인했습니다. 이번에는 같은 로컬 Anvil에서 3자 Escrow를 올리고, 권한과 event를 receipt로 확인합...
로컬 Anvil에 net_peerCount를 보내면 HTTP는 200입니다. 본문은 peers 숫자가 아니라 JSON-RPC 오류입니다. HTTP/1.1 200 OK {"jsonrpc":"2.0","id":1,"error":{"code":-32601,"message":"Method not found"}} 같은 포트에서 eth_syncing은 fa...
JSON-RPC가 HTTP 200을 돌려줘도 그 거래는 성공이 아닐 수 있습니다. receipt의 status가 0x0이면 실행은 되돌려졌고, gas는 이미 소비되었습니다. explorer 화면의 빨간 실패 표시가 가리키는 값이 바로 그 필드입니다. 이전 글에서 출금 순서가 자금을 비울 수 있음을 확인했습니다. 이번에는 실패한 호출을 node가 어떻...
지난 Counter의 increment는 권한이 없었습니다. 숫자가 틀려도 돈은 움직이지 않습니다. 같은 실수가 이더를 들고 있는 금고에서 나면, 출금 함수가 끝나기 전에 다시 출금이 들어옵니다. 이전 글에서 deploy address에 코드가 생긴다는 점을 확인했습니다. 이번에는 그 코드의 호출 순서를 Foundry 테스트로 깨 봅니다. 취약 경로...
이더리움 계정에 코드를 조회했을 때 0x가 나오면 그 address는 EOA입니다. 같은 명령을 방금 deploy한 address에 치면 바이트코드가 나옵니다. 상태 트리의 그 칸에 실행할 프로그램이 올라갔다는 뜻입니다. 이전 글에서 nonce와 21000 gas 이체를 관측했습니다. 이번에는 Foundry 1.7.1로 Counter를 테스트하고 A...