EI4844 CL 클라이언트 구현자 참고 사항

비콘 체인 합의 변경
컨테이너:
BeaconBlockBody 구조 변경

블록 처리:
verify_kzg_commitments_against_transactions 에 추가됨 process_block

네트워킹 변경 사항
컨테이너:
추가 BlobsSidecar및SignedBlobsSidecar

가십 도메인:
수정beacon_block

신체의 kzg 약정이 압축된 BLS G1 포인트(거부)로 인코딩되었는지 확인
본문의 kzg 약정이 tx 목록의 버전이 지정된 해시와 일치하는지 확인(거부)
추가하다blobs_sidecar

사이드카 슬롯이 경계 내에 있는지 확인(무시)
사이드카 Blob이 FE 범위 내에 있는지 확인(거부)
KZG 증명이 압축된 BLS G1 포인트로 인코딩되었는지 확인(거부)
사이드카 서명 확인(거부)
사이드카 제안자가 올바른 슬롯에 있는지 확인(거부)
이것이 주어진 제안자 인덱스 및 슬롯 콤보에 대한 첫 번째 사이드카인지 확인합니다. 여기에 약간의 안티 도스 조치
⚠️ validate_blobs_sidecar가십 전에 검증의 일부가 되어야 합니까? 현재 명시된 바와 같이 validate_blobs_sidecar포크 선택에만 영향을 미칩니다 .

⚠️ 현재 네트워크 사양을 기반으로 사이드카를 블록 없이 검증 및 전파할 수 있습니다. 의도한 것입니까?

요청/해상도 도메인:
수정 /eth2/beacon_chain/req/beacon_blocks_by_range/2/
수정 /eth2/beacon_chain/req/beacon_blocks_by_root/2/
추가BlobsSidecarsByRange v1

요청: start_slot: Slot,count: uint64
응답:List[BlobsSidecar, MAX_REQUEST_BLOBS_SIDECARS]
응답은 현재 헤드로 이어지는 내용에 의해 결정됩니다.
⚠️없으니 참고하세요 BlobsSidecarsByRootv1. 내 첫인상은 이것이 있으면 유용하다는 것입니다. 가십에서 사이드카를 받지 못했다면 최소한 빨리 검색할 수 있습니다.

⚠️ MAX_REQUEST_BLOBS_SIDECARS는 128입니다. 사이드카의 대상 크기는 ~1MB이고 최대값은 ~2MB입니다. 이것이 저대역폭 장치에 어떤 영향을 줍니까?

4844 동안 네트워킹 계층의 s 및 s 결합에 대한 몇 가지 추가 참고 사항 .BeaconBlockBlob

검증인 변경
Validator signed_blobs_sidecar는 추가로 제안합니다 signed_beacon_block. 유효성 검사기는 get_blobs_and_kzg_commitments입력이payload_id

⚠️ 이상적으로는 통합되어야 합니다 get_blobs_and_kzg_commitments. get_payload하나의 요청으로 얼룩과 페이로드를 검색하는 것이 좋습니다.

유효성 검사기는 페이로드 트랜잭션의 유효성을 검사하고 blob 및 kzg 약정이 모두 정렬된 다음 blobs_sidecar서명을 위해 구성합니다. 집계된 다항식(blobs)을 계산하고 kzg 증명을 위해 이를 bls 필드에 해시하는 필드가 있습니다 blobs_sidecar.kzg_aggregated_proof

⚠️ 요즘은 시간이 얼마나 걸리는지 모르겠지만 좋은 최적화 목표라고 생각합니다.compute_proof_from_blobs

Blob 백필 요구 사항
와 유사하게 SignedBeaconBlock클라이언트는 블록을 최대 current_epoch – MIN_EPOCHS_FOR_BLOCK_REQUESTS.
체크포인트 동기화에서 시작하는 CL 클라이언트는 다음까지 백업 BlobsSidecar해야 합니다.current_epoch – MIN_EPOCHS_FOR_BLOBS_SIDECARS_REQUESTS

⚠️ CL 클라이언트는 백필에 대해 어떤 종류의 유효성 검사를 수행해야 BlobsSidecar합니까? 가 아니므로 서명을 확인할 수 없습니다 SignedBlobsSidecar. 최소한 수행할 수 validate_blobs_sidecar있습니까? DB의 비콘 블록과 교차 확인합니까? (이 영역은 사양에서 정의되지 않음)

반대 인수 SignedBlobsSidecarsByRange는 노드가 비콘 블록을 갖기 전에 역사적으로 블롭을 다운로드할 수 있다는 것입니다. 어쨌든 블록을 얻을 때까지 동기화 중인 역사적 블롭에 대한 제안자를 알 필요가 없을 수도 있습니다.

기록 동기화를 위해 다음 세 가지 작업을 수행할 수 있습니다.

kzg 증명 확인
제안자 서명 확인
Blob이 표준 체인의 일부인지 확인
1은 필수라고 생각합니다. 2와 3은 같은 객체 아래에서 블롭과 블록을 결합하는 경우에만 의미가 있습니다.
동기화에는 두 가지 방법이 있습니다. 순방향 동기화 및 역방향 동기화 w/ws 상태. 역방향 동기화의 경우 Blob에는 parent_root 필드가 없고 체인이 아니므로 실제로 개별 단위로 하나씩 유효성을 검사해야 합니다.
…

스토리지 요구 사항
비콘 클라이언트는 SignedSideCar최대 MIN_EPOCHS_FOR_BLOBS_SIDECARS_REQUESTS. N클라이언트는 에포크 기준으로 일부 롤링 창 정리 메커니즘을 구현할 것 입니다.
추가 저장 요구 사항에 관해서. 최악의 경우는 다음과 같습니다. MIN_EPOCHS_FOR_BLOBS_SIDECARS_REQUESTS* SLOTS_IN_EPOCH* 2MB는 ~525GB입니다 .

1MB/2MB(목표/최대)의 경제성은 장기적으로 평균 1MB가 된다는 점을 명심해야 합니다. 현재 네트워킹에서 1MB/2MB가 현실적인지 여부는 두고 봐야 합니다. 가능한 트레이드 오프는 네트워크 복잡성을 증가시키거나 값을 낮추는 것입니다. 마지막으로 4주( MIN_EPOCHS_FOR_BLOBS_SIDECARS_REQUESTS)의 상한선을 2주로 낮출 수 있습니다. 최악의 경우 계산 ~ 525GB는 훨씬 낮을 것입니다.

MIN_EPOCHS_FOR_BLOBS_SIDECARS_REQUESTS⚠️ 이타적 노드가 더 긴 기간 동안 얼룩을 저장할 수 있도록 승수를 활성화하기 위해 CLI 플래그를 추가하는 것이 도움이 되는지 궁금합니다 . 단점은 이러한 디자인이 매우 낮은 숫자 로 하드코딩하는 사람이 남용할 수 있다는 것입니다 .MIN_EPOCHS_FOR_BLOBS_SIDECARS_REQUESTS

네트워킹 요구 사항
현재 가십 성능 및 노드 대역폭 고려 사항을 고려할 때 Blob의 안전한 크기(대상 및 최대값)가 4844인지 확실하지 않습니다.

험담 사이드카 및 요청-응답 사이드카에 필요한 추가 대역폭이 있습니다. 현재 게시된 권장 사항은 최소 10Mb/s 대칭 및 “권장” 25Mb/s입니다: https://ethereum.org/en/developers/docs/nodes-and-clients/ . 이 범위의 노드 네트워크를 가정할 때 현재 비콘 체인 슬롯 구조가 주어지면 네트워크가 처리할 수 있는 안전한 Blob 크기는 얼마입니까(4초 이전에 광범위한 보급 필요).

이 값을 조정하기 위해 수행해야 하는 펜과 종이 및/또는 실험적 분석이 있습니까?

대역폭 문제를 해결하는 몇 가지 방법이 있습니다.

증폭 인자 감소
최대 얼룩 크기 줄이기
Blob 푸시 vs 풀
블롭 사이드카를 선택 주제
로 설정 가십 증폭 요인을 살펴보고 대역폭 측정 시스템을 기반으로 증폭을 조정할 수 있습니다. Go libp2p는 추적할 피어 기준으로 리소스 측정 시스템을 지원합니다. 속도 제한은 응용 프로그램 계층(req/res 제한) 및 gossipsub에서 발생할 수 있습니다.
사이드카 없이 차단 == 낙관적 차단?
사이드카 컴패니언이 없는 블록은 유효한 것으로 간주되지 않지만 처리해도 됩니다. 요구 사항을 참조하십시오 is_data_available. 사양에 명시된 대로 블록은 “낙관적으로” 처리될 수 있습니다.
⚠️ SYNCING/ ACCEPTED페이로드가 있는 블록과 사이드카가 없는 블록 사이에 어떤 평행선을 그릴 수 있습니까? 현재 Prysm 디자인은 사이드카가 없는 블록을 헤드로 간주하지 않습니다. 이내에filter_block_tree

if correct_justified and correct_finalized and is_data_available:
blocks[block_root] = block
return True
EL이 보고하면 그러한 블록을 검증하는 것이 제정신인 것 같습니다 INVALID. 그런 VALID다음 노드가 즉시 찾을 수 없는 경우 각각의 얼룩을 찾습니다. 사이드카가 없는 블록은 의미가 없습니다. 낙관적 모드가 존재하는 이유는 노드가 동기화/복구를 시도하기 위해 EL 클라이언트 헤드를 계속 보낼 수 있기 때문입니다. 이 경우 EL 클라이언트는 동기화되지 않으므로 낙관적인 것은 부가가치가 많지 않습니다.

KZG 시행 현황
구현 전반에 걸쳐 사용할 최상의 라이브러리를 결정해야 합니다. 모든 CL 팀에서 단일 라이브러리 사용으로 이를 수렴하는 것이 좋을 것입니다.
저는 George가 Supranational 팀과 이야기하고 요청된 기능 목록을 제공했다고 생각합니다. Discord 를 기반 으로 하면 이것이 go

• compute_powers()
  kzg matrix_lincomb()
  를 완전히 대체할 수 있도록 blst 가 노출할 것으로 예상되는 KZG/다항식 함수의 목록이라고 생각 합니다 . 성능에 민감한 기능을 위해 만들어진 예외를 제외하고 blst가 제공하는 모든 기본 기능. BLST에는 이미 필드 요소에서 작동하는 기능이 포함되어 있습니다. 따라서 지금 당장 BLST를 사용하여 사양에서 성능에 중요하지 않은 기능을 많이 구현할 수 있습니다.g1_lincomb()
  bytes_to_bls_field()
  evaluate_polynomial_in_evaluation_form()
  verify_kzg_proof()
  compute_kzg_proof()

BLST에서 지원하지 않는 누락된 기능을 채우는 Dankrad와 Ben이 작업 중인 c-kzg 라이브러리 도 있습니다 . c-kzg는 Supranational이 KZG 기능을 추가하는 데 너무 오래 걸리는 경우 단기적으로 유용할 수 있습니다.

현재 devnet 및 Prysm 프로토타입은 BLS 사전 컴파일을 지원하기 위해 이전에 Geth가 분기한 Kilic-BLS 위에 래핑되는 Go-KZG 유형을 사용합니다. 이것은 CL 클라이언트에서 사용되지 않습니다.
Go-KZG에는 다른 BLS 라이브러리를 사용할 수 있는 옵션이 있습니다. BLST를 시도했지만 메모리 관리가 부족하여 어려웠습니다. CGO 유형을 Go 유형으로 래핑하는 것은 어렵습니다.
현재 BLST는 일부 작업 요구 사항을 노출하지만 모든 작업이
Supranational은 아니지만 현재 페어링을 위한 인터페이스가 매우 번거롭고 문서를 개선할 것이라는 데 동의했습니다.

번역본 원문 작성자: @terencechain