Ethereum 트랜잭션 처리 메커니즘에 대한 심층적 이해

创宇区块链安全实验室

特邀专栏作者

2021-06-17 11:07 (UTC+8)

이 기사는 약 5380자로, 전체를 읽는 데 약 8분이 소요됩니다

소스 코드의 관점에서 이더리움 트랜잭션 풀 데이터 구조의 논리적 설계, 트랜잭션 수수료 설정, 트랜잭션 구성, 트랜잭션 풀링, 트랜잭션 서명, 트랜잭션 검증 등을 간략하게 분석하고 퍼블릭

AI 요약

펼치기

머리말

첫 번째 레벨 제목"머리말"、"블록체인은"탈중앙화"불신"를 통해 집합적으로 유지되는 분산 원장"분산"원장

블록체인은 당연히 장부 기록에 없어서는 안 될 존재이며 거래가 자연스럽게 최우선 순위가 됩니다. Chuangyu Blockchain Security Lab은 이더리움 트랜잭션 풀 데이터 구조의 논리적 설계, 트랜잭션 수수료 설정, 트랜잭션 구성, 트랜잭션 풀링, 트랜잭션 서명, 트랜잭션 검증 등을 소스 코드의 관점에서 그리고 Fang 트랜잭션을 통해 간략하게 분석할 것임을 알고 있습니다. 퍼블릭 체인 보안 메커니즘 설계를 연구하기 위한 보안 메커니즘 설계.

첫 번째 레벨 제목

기본 사상

트랜잭션 프로세스의 개략도는 대략 다음과 같습니다.
흐름 설명:

먼저 사용자는 네트워크를 통해 트랜잭션 요청을 시작하고 자신의 개인 키로 트랜잭션에 서명한 다음 트랜잭션을 브로드캐스트한 다음 트랜잭션을 트랜잭션 풀에 추가합니다.채굴자는 트랜잭션 풀에서 트랜잭션 정보를 얻은 다음 패키징하고 생성한 다음 합의를 통해 블록을 생성하고 최종적으로 트랜잭션 블록을 전체 네트워크에 브로드캐스팅합니다.
데이터 흐름:
트랜잭션 풀의 데이터 소스:
원격 동기화는 브로드캐스트 동기화 형식을 통해 다른 이더리움 노드의 트랜잭션 데이터를 로컬 노드에 동기화합니다.

트랜잭션 풀의 데이터 위치: 채굴자(채굴자)가 획득 및 확인, 채굴에 사용, 블록에 기록되고 채굴이 성공한 후 브로드캐스트되며 트랜잭션이 기록된 후 트랜잭션 풀에서 삭제됨 캐노니컬 체인, 트랜잭션이 작성되면 포크에 들어간 후 트랜잭션 풀의 트랜잭션이 줄어들지 않고 재포장을 기다립니다.

첫 번째 레벨 제목

데이터 구조

기본 구성은 다음과 같습니다.

TxPool 데이터 구조는 다음과 같습니다.

첫 번째 레벨 제목

트랜잭션 실행을 분석할 때 트랜잭션 수수료 상한/하한이 있는지 여부, 트랜잭션 풀 구성, 최대 트랜잭션 정보 검색 횟수 등과 같은 몇 가지 기본 구성을 먼저 살펴볼 필요가 있습니다. 몇 가지 핵심 사항:

보조 제목

02 거래 풀 구성

보조 제목

03 트랜잭션 검색 수량

풀 초기화

트랜잭션 풀의 초기화는 NewTxPool을 통해 구현되며 구체적인 코드는 다음과 같다.

여기에서 불합리한 가스 가격 설정을 피하기 위해 구성 매개 변수를 확인하기 위해 위생 처리 기능이 먼저 호출됩니다.

그런 다음 기본 구성으로 트랜잭션 풀( txpool )을 초기화합니다.

그런 다음 로컬 계정을 초기화하고 구성된 로컬 계정 주소를 트랜잭션 풀에 추가합니다.

그런 다음 가스 가격이 더 높은 주문 거래를 생성합니다.

구체적인 구현 코드는 다음과 같습니다.

그런 다음 reset을 호출하여 트랜잭션 풀을 업데이트합니다.

재설정의 구체적인 구현은 다음과 같습니다.

그런 다음 로그 로드 중에 생성된 요청을 처리할 수 있도록 reorg 루프를 시작합니다.

scheduleReorgLoop의 구체적인 구현 코드는 아래와 같으며, 이 함수는 주로 reset 및 promotionExecutable의 실행 계획에 사용됩니다.

그런 다음 관련 트랜잭션 이벤트를 구독하고 메인 루프를 시작합니다.

메인 루프 루프의 구체적인 구현 코드는 다음과 같습니다.txPool의 고루틴이자 메인 이벤트 루프입니다.주로 외부 블록체인 이벤트와 다양한 보고서 및 트랜잭션 제거 이벤트를 대기하고 응답하는 데 사용됩니다.

첫 번째 레벨 제목

빌드 트랜잭션

거래는 사용자에 의해 시작되어 자산이 한 당사자에서 다른 당사자로 전송되는 소위 가치 이전입니다.우리의 가장 직관적인 트랜잭션 구성은 지갑을 통해 돈을 이체하는 것입니다.여기서 우리는 RPC의 RPC를 직접 사용합니다. eth_sendTransaction 트랜잭션의 구성 과정을 분석하기 위한 예로, eth_sendTransaction 요청의 예제는 다음과 같습니다.
예시 매개변수:
from: DATA, 20바이트 - 보내는 트랜잭션의 소스 주소
to: DATA, 20바이트 - 트랜잭션의 대상 주소, 새 계약을 만들 때 선택 사항
gas: QUANTITY - 트랜잭션 실행에 사용 가능한 가스 양, 선택적 정수, 기본값 90000, 사용하지 않은 가스가 반환됩니다.
gasPrice: QUANTITY - 가스 가격, 옵션, 기본값: To-Be-Determined
값: QUANTITY - 거래에서 보낸 금액, 선택적 정수

데이터: DATA - 계약 컴파일 또는 호출된 메서드의 서명 및 인코딩 매개변수

nonce: QUANTITY - nonce, optional, 동일한 nonce를 사용하여 보류 중인 트랜잭션을 다시 작성할 수 있음

응답 예시:"RPC인 eth_sendTransaction의 실행 과정을 추적해 보자."SignTx의 구현 코드는 다음과 같습니다. 서명 작업을 위해 SignTx가 계속 호출되므로 여기에서 자세히 설명하지 않고 후속 작업을 수행합니다.

트랜잭션 서명

세분화된 분석이 수행됩니다."서명 후 SendTransaction으로 돌아가 SubmitTransaction을 호출하여 서명을 제출합니다.여기서 먼저 거래 수수료가 충분한지 확인한 다음 SendTx를 호출하여 거래를 보냅니다."SendTx의 구체적인 구현은 다음과 같으며 여기서 AddLocal을 호출하여 트랜잭션 풀에 트랜잭션을 추가합니다.

이 하나의 분석 단위 모듈:

그런 다음 수신 주소가 비어 있는지 확인하고 비어 있으면 주소를 생성(일반적으로 계약 생성 시 나타남)한 다음 후속 수동 조사 및 분석을 위해 전체 TX 세부 정보 로그를 인쇄한 다음 해당 해시 값을 반환합니다. 거래:

첫 번째 레벨 제목

수영장으로 거래

우리는 트랜잭션의 두 가지 소스가 있다는 것을 알고 있습니다: 하나는 로컬로 제출되고 다른 하나는 원격으로 제출됩니다.이 두 가지의 특정 구현 코드는 각각 AddLocals 및 AddRemotes입니다.이 두 기능은 트랜잭션 풀에 트랜잭션을 추가할 때 사용됩니다.이것은 addTxs를 호출하여 달성:

addTxs 코드는 다음과 같습니다.

먼저 트랜잭션을 필터링하여 알려진 트랜잭션(즉, 추가 또는 브로드캐스트)인지 확인한 다음 send 함수를 호출하여 secp256k1 타원 곡선을 통해 서명(v, r, s)에서 파생된 주소를 확인합니다. , 파생된 경우 실패하거나 잘못 서명된 경우 오류를 반환합니다.

그런 다음 트랜잭션 풀에 트랜잭션을 추가합니다(참고: 여기에 트랜잭션 잠금이 있음).

addTxsLocked의 구체적인 구현은 다음과 같습니다. 유효한 트랜잭션을 큐에 넣고 pool.add 함수를 호출하여 트랜잭션을 트랜잭션 큐에 추가합니다.

add 함수의 구체적인 구현은 다음과 같습니다.

여기에서 먼저 현재 트랜잭션이 알려져 있는지(즉, 브로드캐스트되었거나 풀에 추가되었는지) 확인하고 알려진 경우 직접 폐기합니다.

그런 다음 트랜잭션이 로컬로 제출되었는지 원격으로 제출되었는지 확인하고 validationTx 함수를 호출하여 트랜잭션을 확인합니다. 확인에 실패하면 바로 폐기됩니다.

그런 다음 트랜잭션 풀이 가득 찼는지 확인하고 가득 차면 트랜잭션 대기열에서 저평가된 트랜잭션을 폐기합니다. GlobalSlots 및 GlobalQueue는 보류 및 대기열의 최대 용량입니다.

그런 다음 현재 트랜잭션의 pending queue에 동일한 nonce 값을 가진 트랜잭션이 있는지 판단하고, 존재할 경우 현재 거래소에서 설정한 gasprice가 설정된 PriceBump 비율을 초과하는지 판단하고, 초과할 경우 기존 트랜잭션을 대체하여 덮어씁니다. . 그렇지 않으면 오류가 반환되고 대체 트랜잭션의 Gasprice가 너무 낮습니다. , 큐에 넣습니다( enqueueTx ):

enqueueTx를 호출한 후 트랜잭션 대기열에 추가되며 동시에 from 계정이 로컬 주소인지 확인하고 그렇다면 트랜잭션 풀의 로컬 주소에 추가합니다.

enqueueTx 코드는 다음과 같습니다. 이 함수는 주로 트랜잭션 대기열에 새 트랜잭션을 삽입합니다.

마지막으로 addTx 함수로 이동합니다. 여기에서 requestPromoteExecutables 함수가 호출되어 주로 트랜잭션을 대기열에서 보류 중인 트랜잭션으로 전환하는 트랜잭션 승격 요청 작업을 수행합니다.

트랜잭션 서명

트랜잭션 서명은 주로 SignTx 함수에 의해 구현되며, 먼저 지갑이 닫혀 있는지 확인한 다음 지갑 계정에 발정 거래 요청 계정이 포함되어 있는지 확인한 다음 서명 처리를 위해 SignTx를 호출합니다.

SignTx의 구체적인 구현 코드는 다음과 같습니다.

ECDSA(Elliptic Curve Encryption Algorithm)를 사용하여 로그인한 다음 서명된 결과를 반환합니다.

거래 확인

첫 번째 레벨 제목

거래 확인
트랜잭션 검증은 전체 트랜잭션 링크에서 가장 중요한 부분입니다.사용자에게 트랜잭션 검증은 사용자 자산의 안전을 보장하는 중요한 수단입니다.전체 이더리움에게 트랜잭션 검증은 안정적인 운영과 지속 가능한 발전을 보장하는 중요한 방법입니다. , 트랜잭션 확인은 주로 다음 시나리오에서 발생합니다.
사용자가 트랜잭션 서명을 완료하면 블록체인 네트워크에 트랜잭션을 제출해야 트랜잭션이 가능한 한 빨리 확인될 수 있으며 노드는 트랜잭션을 제출하기 전에 트랜잭션의 적법성을 확인하기 위해 트랜잭션을 확인해야 합니다. 거래;
노드가 다른 노드에 의해 브로드캐스트된 거래를 수신하면 노드는 거래가 합법적인지 확인해야 하며 합법적인 거래는 노드의 거래 풀에 추가됩니다.

노드가 다른 노드에 의해 동기화된 블록을 수신하면 블록에 포함된 트랜잭션도 확인해야 합니다.

트랜잭션 검증은 validateTx 함수에 의해 완료되며 그 로직 코드는 다음과 같습니다.여기서 eip2718 활성화 여부와 트랜잭션 유형을 확인한 다음 트랜잭션 크기, 트랜잭션 전송 금액, 가스를 확인합니다. 거래의 정확성, 거래 서명의 정확성 및 거래 보장 Nonce 주문을 따르고 거래자의 자산이 충분한지 여부와 거래 가스 가격을 보장합니다.기본 거래 수수료가 높습니다.

첫 번째 레벨 제목

트랜잭션 업그레이드

트랜잭션 업그레이드는 주로 트랜잭션을 보류 목록에 넣는 것을 의미하며, 이 방법과 추가 방법의 차이점은 추가 기능은 획득한 새 트랜잭션을 보류에 삽입하는 반면 PromoteExecutables는 실행 파일을 지정된 계정 주소 목록에 넣는다는 것입니다. queue list에서 Pending에 삽입하고 유효하지 않은 트랜잭션을 확인한 다음 트랜잭션 풀 업데이트 이벤트를 전송합니다.구현 코드는 다음과 같습니다.

여기에서 for 루프는 모든 계정을 반복하고 트랜잭션을 업그레이드하는 데 사용됩니다. 여기에서 먼저 계정의 현재 nonce보다 nonce가 낮은 대기열의 모든 트랜잭션이 삭제됩니다.

그런 다음 소비가 계정이 보유한 잔액보다 크거나 가스가 최대 가스 한도보다 큰 대기열의 모든 트랜잭션을 제거합니다.

그런 다음 대기열의 모든 실행 가능한 트랜잭션을 보류 상태로 추가합니다. 여기에서 대기열의 트랜잭션( Txs )을 보류 상태로 만들기 위해 promotionTx 메서드가 호출됩니다.

promotionTx의 구현 코드는 다음과 같습니다.이 기능은 먼저 트랜잭션을 대기 중인 대기열에 삽입합니다.이전 트랜잭션이 더 나은 경우(트랜잭션 Gasprice가 원래 트랜잭션 값의 110%보다 크거나 같으면 표준과 관련됩니다. pricebump 설정), 현재 거래를 삭제합니다. 이 거래는 현재 거래가 이전 거래보다 나은 경우 이전 거래를 삭제한 다음 목록을 업데이트합니다.

그런 다음 promotionExecutables 함수로 돌아가서 로컬이 아닌 계정 대기열이 제한( AccountQueue )보다 작으면 제거합니다.

마지막으로 제거된 항목을 기록하고 queuedGauge를 업데이트합니다. 대기열에 있는 이 계정의 트랜잭션이 비어 있으면 이 계정을 삭제합니다.

트랜잭션 다운그레이드
트랜잭션 다운그레이드는 새로운 블록이 나타날 때 패키징된 트랜잭션이 패딩에서 큐로 다운그레이드되거나 다른 트랜잭션의 가스 가격이 높을 때 패딩에서 큐로 다운그레이드되는 것을 의미합니다. 구현 기능은 demoteUnexecutables이며 트랜잭션 다운그레이드는 주로 다음 세 가지 상황에서 발생합니다.
포크는 Account의 Nonce 값을 감소시킵니다. 원래 캐노니컬 체인 A의 거래 번호 m이 20이고 이미 체인에 있지만 새로운 캐노니컬 체인의 거래 번호 m이 다음 체인에 없는 경우 포크, 결과적으로 캐노니컬 체인에 트랜잭션 번호 m이 기록됩니다. 계정의 Nonce가 감소하므로 트랜잭션 m은 트랜잭션 풀로 롤백되어 대기열에 넣어야 합니다.

포크로 인해 보류 중인 트랜잭션의 논스 값이 상태의 논스 값과 달라집니다.

demoteUnexecutables의 코드는 다음과 같다 여기서 우선 Pending list를 순회하여 각 addr의 최신 Nonce 값을 구한 후 이전 질의로 구한 Nonce 값보다 Nonce가 작은 트랜잭션을 삭제한 후 거래 수수료를 지불하기에 계정 잔액이 부족하여 일부 일시적으로 유효하지 않은 거래가 반환되고 일시적으로 유효하지 않은 거래를 대기열에 넣습니다. 이때 공백이 있으면 다음 거래를 대기열 목록으로 이동합니다. 위의 다운그레이드가 진행되며, Pending 중 특정 주소의 거래가 없을 경우 해당 거래는 삭제됩니다.

첫 번째 레벨 제목

풀 재설정

재설정을 통해 트랜잭션 풀을 재설정할 수 있으며 이 방법의 특정 코드는 다음과 같습니다.

기존 헤드가 null이 아니면 재구성이 시작되는데, 이때 기존 체인의 헤드 블록이 새 체인의 헤드 블록 높이보다 크면 기존 체인은 롤백되고 롤백된 모든 트랜잭션을 재활용합니다. 새 체인의 헤드 블록이 이전 체인의 헤드 블록보다 큰 경우 새 체인은 트랜잭션을 백오프하고 재활용하며 새 체인과 이전 체인이 같은 높이에 도달하면 공통 부모 노드를 찾을 때까지 동시에, 그리고 나서 폐기에 저장되었지만 포함되지 않은 모든 트랜잭션을 찾은 다음 이러한 트랜잭션을 풀에 다시 삽입합니다.

그런 다음 최신 세계 상태를 설정하고 새 체인 헤드 블록의 상태를 설정한 다음 이전 체인이 지원하는 트랜잭션을 트랜잭션 풀에 넣습니다.

첫 번째 레벨 제목"기사 끝의 요약"블록체인은 체인 구조로 서로 연결된 블록으로 구성되며, 각 블록은 블록 헤더와 블록 바디의 두 부분으로 구성됩니다. 블록 바디는 거래 기록을 저장하므로

이 글은 이더리움 트랜잭션 풀 데이터 구조, 트랜잭션 수수료 설정, 트랜잭션 구성, 트랜잭션 서명, 트랜잭션 풀 입력, 트랜잭션 검증, 트랜잭션 업그레이드, 트랜잭션 다운그레이드, 트랜잭션 풀 재설정 등의 기능 모듈을 소스 코드 관점에서 분석한다. 이더리움 트랜잭션 처리의 프로세스 및 보안 설계는 탐색되었지만 퍼블릭 체인 보안 시스템의 구축은 아직 갈 길이 멀고 더 탐색해야 합니다.