작성자 샘 배튼알리, 하이 응우옌, 타인 응우옌. 유용한 피드백과 의견에 대해 린 오시타니와 다닐로 R에게 특별한 감사를 전합니다.
개요
전통적으로 비동기식 트랜잭션 제출 및 확인은 RISE, 메가이더리움 및 플래시블록스 체인(유니체인, 베이스)과 같은 대기 시간에 최적화된 블록체인에 더 이상 적합하지 않습니다. 우리는 기존 이더리움 트랜잭션 워크플로의 주요 한계를 해결하기 위해 간단한 eth_sendRawTransactionSync RPC를 소개합니다.
웹3 API 동작을 익숙한 웹2 요청-응답 패턴과 더 밀접하게 정렬함으로써, eth_sendRawTransactionSync는 개발자 경험을 단순화하고, 대기 시간을 줄이며, 사용자 응답성을 향상시킵니다. 이 간단한 RPC는 블록체인 아키텍처가 더 짧은 블록 시간과 더 빠른 응답성을 향해 진화함에 따라 특히 중요하며, 탈중앙화 및 전통적인 애플리케이션 개발 패러다임 간의 격차를 줄입니다.
동기
기존의 트랜잭션 흐름은 클라이언트가 먼저 eth_sendRawTransaction을 통해 서명된 트랜잭션을 브로드캐스트한 후, eth_getTransactionReceipt를 사용하여 노드에 반복적으로 폴링하여 널이 아닌 영수증이 반환될 때까지 기다리는 비동기 모델을 따릅니다.
이 모델에서 클라이언트는 트랜잭션이 블록에 포함되기를 기다리지 않고 즉시 트랜잭션 해시를 받습니다. 그런 다음 클라이언트는 후속 폴링에 의존하여 트랜잭션의 상태를 결정합니다. 이 접근 방식은 클라이언트가 트랜잭션이 채굴될 때까지 대기하는 동안 멈추거나 응답하지 않는 것을 방지합니다.
비동기 fn send_raw_transaction_sync(&self, tx: 바이트) -> RPC 결과<작업 트랜잭션 영수증> {상수 시간초과_지속시간: 지속시간 = 지속시간::from_secs(2);상수 폴링_간격: 지속시간 = 지속시간::from_millis(1);let 해시 = self.내부.send_raw_transaction(tx).await?;// 분할 자금 지원 대기 블록에서 영수증을 지속적으로 폴링let 시작 = 순간::now();while 시작.elapsed() < 시간초과_지속시간 {if let Some(영수증) = self.대기_블록.get_receipt(해시) {return Ok(영수증);}tokio::time::sleep(폴링_간격).await;}Err(오류객체::owned(-32002,format!("트랜잭션이 메모풀에 추가되었지만 {시간초과_지속시간:?} 내에 처리되지 않았습니다."),Some(해시),))}목록. eth_sendRawTransactionSync 로직의 예시 코드 조각.
시간초과_지속시간=2초와 폴링_간격=1밀리초는 구현 참조이며, 실행 성능에 따라 다른 체인에 대해 다르게 구성될 수 있습니다.
이점
- 대기 시간. 두 번의 RPC 호출 패러다임의 불필요성을 제거함으로써 네트워크 대기 시간이 절반으로 줄어듭니다. 트랜잭션 영수증은 트랜잭션 전송 직후 거의 즉시 사용 가능할 수 있습니다.
- 개발자 경험(DX). 새로운 RPC는 전체 프로세스를 단순화하고 비동기 프로그래밍 및 수동 폴링과 관련된 복잡성을 제거합니다. 개발자는 표준 동기식 API 호출과 유사한 더 깨끗하고 간단한 코드를 작성할 수 있습니다.
- 사용자 경험(UX). RISE의 동기식 방법에서 제공되는 즉각적인 트랜잭션 확인은 네트워크에서 구축된 탈중앙화 애플리케이션과 상호작용하는 개인에게 훨씬 더 부드럽고 반응성 있는 사용자 경험으로 직접 변환됩니다.
- 노드 성능. 노드 운영자의 경우,
eth_sendRawTransactionSync구현은 20줄 이상의 코드로 매우 쉽습니다. 그러나 성능에 큰 영향을 미칩니다.eth_getTransactionReceipt메서드를 사용하여 클라이언트가 트랜잭션 영수증을 반복적으로 쿼리할 필요성을 제거함으로써 노드에 대한 전체 RPC 호출 수를 크게 줄일 수 있습니다.
빠른 비교
다음 표는 트랜잭션 제출의 기존 비동기 접근 방식과 새로운 동기 접근 방식 간의 차이점을 요약합니다.
(이하 생략, 번역 계속됨)
