숫자를 올리는 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...
비트코인에서는 balance를 구하려면 미사용 출력을 모두 더해야 했습니다. 이더리움 node에 같은 질문을 하면 계정 객체에서 balance와 nonce를 읽습니다. 합계를 다시 계산하지 않습니다. 이전 글에서 확인은 활성 팁에 상대적이라는 점을 봤습니다. 이더리움은 그 위에 계정 상태와 gas라는 실행 비용을 올립니다. Foundry Anvil ...
explorer에서 confirmation 1이 뜨면 그 거래는 끝난 것처럼 보입니다. 같은 node에서 그 block을 무효화하면 거래는 다시 mempool로 돌아옵니다. 확인 횟수는 balance처럼 저장되는 플래그가 아니라, 지금 활성 체인 팁에 그 거래가 들어 있는지를 센 값입니다. 이전 글에서 돈은 미사용 출력으로만 존재한다는 점을 확인했습...
block explorer에서 비트코인 wallet을 열면 balance가 딱 붙어 나옵니다. 그런데 비트코인의 데이터 구조 어디에도 balance라는 필드는 없습니다. balance라는 저장된 값을 읽어온다면 어디에 들어 있을까요. 답은 없음입니다. balance는 저장되지 않고, 미사용 출력(UTXO)을 전부 모아 합한 값을 매번 계산해서 보여줄 ...
기능을 다 만들고 나서 테스트를 쓰다 보면, 테스트가 한 번도 실패하지 않고 바로 통과하는 경험이 있습니다. 코드를 고치기 전에도 통과하고, 일부러 버그를 넣어도 여전히 통과한다면 그 테스트는 아무것도 증명하지 않습니다. 반대로 구현보다 테스트를 먼저 쓰면, 테스트는 반드시 한 번은 실패합니다. 이 실패가 정확히 무엇을 증명하는지가 TDD(Test-D...
“blockchain은 암호화되어서 안전하다”는 설명을 자주 봅니다. 그런데 Bitcoin transaction을 block explorer에서 열어보면 송금액, 수신자, 합계가 전부 평문으로 보입니다. 암호화가 핵심이라면 이 내용은 왜 숨겨져 있지 않을까요? blockchain이 암호학으로 푸는 문제는 기밀성이 아닙니다. 무결성과 인증입니다. 누가...