공동 저자 George와 Vlad from Gattaca. 의견 제공에 대해 Aestus, bloXroute, 그리고 Ultrasound 릴레이에 특별한 감사를 전합니다.
개요
이전 릴레이 아키텍처(옵티미스틱 V1 및 V2)에서는 빌더가 사전 검증을 위해 전체 블록 페이로드를 릴레이에 전송해야 했습니다. 이는 상당한 데이터 오버헤드를 의미했습니다: 모든 블록 제출에는 모든 트랜잭션과 블롭 데이터가 포함되어 있어 제출당 메가바이트 단위가 될 수 있었습니다. 이로 인해 제출된 페이로드 중 하나만 반환되고 나머지는 모두 중복되는 엄청난 네트워크 트래픽이 발생하여 릴레이에 무거운 데이터 전송, 처리 및 비용을 부담시켰습니다.
옵티미스틱 V3는 절대적으로 필요한 경우가 아니라면 전체 블록 데이터 전송을 피함으로써 이러한 오버헤드를 제거하도록 설계되었습니다. 핵심 통찰은 경매 목적에 필요한 필수 데이터만 보내는 것입니다. 즉, 블록 헤더, 입찰 추적 및 서명을 보내고, 블록이 실제로 선택될 때까지 무거운 페이로드를 연기하는 것입니다. 이 설계는 대역폭 사용을 크게 줄이고 블록 제출 대기 시간을 단축합니다. 블록 크기의 지속적인 성장, 특히 블롭 제한 증가로 인해 이 접근 방식은 릴레이가 증가하는 처리량 요구를 처리할 수 있도록 보장하는 데 점점 더 중요해지고 있습니다.
(이하 생략, 전체 번역 가능)구조체 헤더제출V3 {/// 이 헤더가 선택된 경우 전체 블록 페이로드를 검색하기 위한 빌더의 서버 엔드포인트를 가리키는 URL/// 전체 블록 페이로드를 검색하기 위한 URL.공개 url: 벡터<u8>,/// 서명된 헤더 데이터. 이는 옵티미스틱 V2 '서명된헤더제출'에서 사용되는 동일한 구조로, 다음을 포함합니다:/// - 실행헤더/// - 입찰추적/// - 서명공개 제출: 서명된헤더제출,}URL은 중계자가 전체 블록을 검색할 수 있는 get_payload_v3 경로를 제공하는 네트워크 주소(예: https://builder.example.com)여야 합니다.
페이로드 검색 (빌더 엔드포인트)
경로: POST /get_payload_v3
중계자가 헤더제출V3에 대한 블록 페이로드를 검색하려면 get_payload_v3 경로의 제공된 URL에 POST 요청을 보냅니다.
구조체 페이로드V3가져오기 {/// `서명된헤더제출`의 블록 헤더 해시.공개 블록_해시: B256,/// 중계자가 이 요청을 보낸 타임스탬프 (밀리초 단위).공개 요청_타임스탬프: u64,/// `서명된페이로드V3`의 `서명` 필드를 생성하는 데 사용된 서명 키의 Bls 공개 키.공개 중계자_공개키: Bls공개키,}구조체 서명된페이로드V3 {공개 메시지: 페이로드V3가져오기,/// 중계자가 `get_header` 응답에 서명하는 데 사용하는 키의 서명공개 서명: Bls서명,}블록_해시 필드는 요청된 블록의 해시입니다. 요청_타임스탬프는 중계자가 이 요청을 보낸 시간의 밀리초 UTC 타임스탬프입니다.
응답 본문
빌더는 표준 빌더 제출과 동일한 서명된빌더입찰 유형으로 전체 블록 페이로드를 반환해야 합니다.
