Relay 시맨틱
이 문서는 개발자가 대체 Peggy relayer를 구현하는 데 도움을 주기 위해 설계되었습니다. Ethereum과 상호작용하는 Orchestrator의 두 가지 주요 구성 요소입니다. Peggy 브릿지는 사용 편의성이 아닌 효율성 향상을 위해 설계되었습니다. 이것은 이 문서가 명시적으로 만들기 위해 최선을 다하는 외부 바이너리의 많은 암묵적 요구 사항이 있음을 의미합니다. Peggyorchestrator는 Peggy 브릿지에서 외부 바이너리가 수행해야 하는 세 가지 별개의 역할을 결합합니다. 이 문서는 orchestrator에 포함된 역할 중 하나인 relayer의 요구 사항을 강조합니다.
검증자 세트 업데이트 중계 시맨틱
검증자 세트 및 서명의 정렬과 순서
Peggy 컨트랙트에서 검증자 세트를 업데이트할 때 이전 검증자 세트의 복사본을 제공해야 합니다. 이것은 반드시 Ethereum 체인의 마지막 ValsetUpdated 이벤트에서만 가져와야 합니다. 이전 검증자 세트를 제공하는 것은 저장소 최적화의 일부입니다. 전체 검증자 세트를 Ethereum 저장소에 저장하는 대신 각 호출자가 제공하고 훨씬 저렴한 Ethereum 이벤트 큐에 저장됩니다. Peggy 컨트랙트에서는 어떤 종류의 정렬도 수행되지 않습니다. 즉, 검증자 목록과 새 서명은 마지막 호출과 정확히 동일한 순서로 제출되어야 합니다. 정상 작동을 위해 이 요구 사항은 ‘검증자를 내림차순 파워로 정렬하고, 파워가 같은 경우 Eth 주소 바이트로 정렬’로 단축할 수 있습니다. peggy 모듈이 검증자 세트를 생성하므로 항상 순서대로 와야 합니다. 서명의 일부이므로 relayer가 이 순서를 변경하는 것은 불가능합니다. 그러나 Peggy 모듈 측에서 이 정렬 방법이 변경되면 구현이 마지막으로 제출된 순서를 맹목적으로 정렬을 따르지 않고 확인할 만큼 충분히 똑똑하지 않으면 valset 업데이트가 중단되고 본질적으로 브릿지가 분리됩니다.어떤 검증자 세트를 중계할지 결정
Injective Chain은 단순히 검증자 세트 스트림을 생성하며, 중계 방법에 대한 어떤 판단도 하지 않습니다. 이 중계 작업의 가스 비용을 최적화하는 방법을 결정하는 것은 relayer 구현에 달려 있습니다. 예를 들어 검증자 세트A, B, C, D가 있다고 가정해 봅시다. 각각은 저장소의 마지막 Peggy 검증자 세트 스냅샷과 현재 활성 검증자 세트 사이에 5% 파워 차이가 있을 때 생성됩니다.
5%는 임의의 상수입니다. 여기서 선택한 특정 값은 Ethereum 검증자 세트가 얼마나 최신 상태인지와 최신 상태를 유지하는 비용 사이의 체인에 의해 이루어진 트레이드오프입니다. 이 값이 높을수록 최악의 경우 브릿지를 하이재킹하는 데 필요한 투표 검증자 세트의 비율이 낮습니다. 모든 블록에서 새 검증자 세트 업데이트를 만들면 66%가 공모해야 하고, 5% 변경 임계값은 주어진 검증자 세트에서 전체 투표 권한의 61%가 공모하면 브릿지의 자금을 훔칠 수 있음을 의미합니다.
eth_call() Ethereum RPC를 단순히 사용할 수 있습니다.
eth_call()에는 종종 재미있는 문제가 있습니다. 가스 비용을 지불할 Ethereum이 없으면 Geth 기반 구현에서 모든 호출이 실패하고, Parity 기반 구현에서는 가스 입력이 대부분 무시되고 정확한 가스 사용량이 반환됩니다.
트랜잭션 배치 중계 시맨틱
트랜잭션 배치를 제출하려면 마지막 검증자 세트와 스테이킹 파워도 제출해야 합니다. 이것은 거기에 언급된 동일한 저장소 최적화를 용이하게 하기 위한 것입니다.어떤 배치를 중계할지 결정
어떤 배치를 중계할지 결정하는 것은 어떤 검증자 세트를 중계할지 결정하는 것과 매우 다릅니다. 배치 중계는 브릿지의 무결성을 유지하려는 욕구가 아니라 주로 수수료에 의해 동기 부여됩니다. 따라서 결정은 주로 수수료 계산으로 귀결되며, 이것은 ‘배치 요청’의 개념으로 인해 더욱 복잡해집니다. 이것은 Peggy 모듈이 특정 토큰 유형에 대한 새 배치를 생성하도록 요청하는 권한이 없는 트랜잭션입니다. 배치 요청은 relayer가 실제로 중계하는 데 관심을 보일 때까지 사용자가 언제든지 send to Ethereum tx 풀에서 토큰을 출금할 수 있도록 설계되었습니다. 트랜잭션이 풀에 있는 동안 사용자가 MsgCancelSendToEth를 보내 출금할 수 있다면 이중 지출 위험이 없습니다. ‘요청 배치’로 인해 트랜잭션이 배치에 들어가면 Oracle이 사용자의 토큰이 포함된 배치가 제출하기에 어떻게든 유효하지 않게 되었거나 Ethereum에서 실행되었음을 Peggy 모듈에 알릴 때까지 사용자의 자금은 잠긴 상태로 유지되어야 합니다. relayer는 쿼리 엔드포인트BatchFees를 사용하여 각 토큰 유형에 대한 send to Eth tx 풀을 반복합니다. 그런 다음 relayer는 dex에서 중계되는 ERC-20 토큰의 가격을 관찰하고 배치 실행 가스 비용(eth_call() 통해)과 원하는 경우 dex에서 수익을 청산하는 가스 비용을 계산할 수 있습니다. relayer가 배치가 좋고 수익성이 있다고 판단하면 MsgRequestBatch를 보낼 수 있고 relayer가 중계할 배치가 생성됩니다.
기존 배치도 있으며, relayer는 거의 동일한 방법을 사용하여 수익성을 판단하고 중계를 시도해야 합니다.