신뢰 없는 크로스 체인 자산 전송에 대하여.
주의: 이 프로토콜의 초기 개발은 Viaduct라는 이름으로 시작되었습니다.
서문
현재 이더리움 상태에서 레이어 2 블록체인은 서로 그리고 이더리움 메인넷과 단편화되어 있습니다. 이 문제를 해결하고 효과적인 상호운용성을 달성하는 핵심 요소 중 하나는 크로스 체인 자산 전송입니다. 많은 브리지가 이 기능을 구현하지만, 어느 정도 신뢰에 의존하는 방식으로 그렇게 합니다.
그러나 서명 기반 거래 시스템을 사용하면 신뢰 없이 여러 네트워크 간에 토큰 전송을 미러링할 수 있습니다. 유일한 신뢰 가정은 최소 하나의 정직한 노드가 존재하고 네트워크가 합리적으로 짧은 시간 내에 거래를 감지하고 중계할 수 있다는 것입니다.
1부: 단일 배포
첫 번째 단계는 단일 스마트 계약에서 신뢰할 수 있는 서명 기반 전송을 처리할 수 있는 시스템을 만드는 것입니다. 이 프로토콜은 이러한 전송을 세 부분으로 나눕니다: 검색, 서명, 실행.
검색 단계에서는 프로토콜의 핵심 스마트 계약에 getValidHash()를 호출합니다. 이 메서드는 보낸 사람, 받는 사람, 금액, 논스를 받아 요청된 전송의 해시를 계산하고 반환합니다.
그 다음에는 서명 단계가 옵니다. 계약이 계산을 완료하면 거래 보낸 사람이 결과 해시에 서명하여 거래를 승인할 수 있습니다. 서명은 한 번의 전송에만 유효합니다. 보낸 사람이 거래를 반복하려면 새 논스를 사용하여 새 해시와 서명을 계산할 수 있습니다.
마지막으로 실행 단계에서는 거래 서명에 액세스할 수 있는 누구나 핵심 계약에 objectiveTransfer()를 호출할 수 있습니다. 중복 지출 및 서명 정확성을 확인한 후 계약은 보낸 사람에서 받는 사람으로 올바른 수의 토큰을 전송합니다. 서명자 또는 소위 중계 노드가 objectiveTransfer() 호출을 시작할 수 있습니다. 중계 노드는 전송 프로세스에 수수료를 부과할 수 있습니다.
이 시스템은 서명과 중계를 통한 토큰 전송을 허용합니다. 이 시점에서 이 설계는 Uniswap의 Permit2와 같은 시스템의 장단점을 복제합니다.
2부: 크로스 배포
신뢰할 수 없는 서명 전송 시스템을 만드는 다음 단계는 동일한 블록체인에서 핵심 계약의 여러 배포 또는 인스턴스에서 이 프로토콜이 작동할 수 있도록 하는 것입니다. 지금은 관련이 없어 보일 수 있지만, 이는 크로스 체인 전송을 위한 중요한 인프라 요소를 형성합니다.
각 배포는 다른 배포의 목록을 추적할 수 있습니다. 모든 배포가 모든 다른 배포를 인식할 필요는 없습니다. 필요한 것은 두 인스턴스 간에 직접 또는 간접적인 경로가 있다는 것뿐입니다. 그런 다음 배포가 유효한 목적 전송을 받을 때마다 자체 피어 체인에서 동일한 전송 호출을 시작할 수 있습니다. 이러한 체인은 호출이 올바른지 독립적으로 확인한 다음 전송을 실행하고 잔액을 적절히 재계산할 수 있습니다.
여러 인스턴스에서 동시에 토큰을 중복 지출하려는 시도는 실패할 것입니다. 각 인스턴스가 동일한 블록체인에 있기 때문에 서명자는 동시에 여러 거래를 실행할 수 없습니다. 이는 모든 배포가 동기화된 상태를 유지하고 모든 중복 지출 시도를 차단한다는 의미입니다.
3부: 격리된 크로스 배포
이제 핵심 계약 배포 또는 인스턴스에는 서로 통신하지 않고도 프로토콜의 안전한 버전을 실행할 수 있는 방법이 필요합니다. 크로스 배포 거래 실행을 가능하게 하려면 온체인 목적 전송을 모니터링하고 각 배포에 중계하는 비허가형 중계 노드 네트워크가 있을 수 있습니다.
그러나 이 시점에서 프로토콜에는 중대한 결함이 여전히 존재합니다. 동일한 보낸 사람이 두 개의 다른 배포에서 동시에 두 개의 거래를 시작하여 보낸 사람의 잔액의 50% 이상을 두 개의 다른 주소로 보내는 경우 보낸 사람은 중복 지출할 수 있습니다. 두 배포 모두 처음에 받지 않은 거래를 거부하고 계정 잔액이 달라질 것입니다.
중복 지출 문제를 해결하기 위해 핵심 계약은 챌린지 창을 사용합니다. 각 창은 w_fwf초 동안 지속되며 제안 기간과 챌린지 전용 기간의 두 기간으로 구성됩니다. 제안 기간과 챌린지 전용 기간은 각각 w_pwp초와 w_cwc초 동안 지속됩니다. 핵심 스마트 계약은 챌린지 전용 기간 동안 objectiveTransfer() 기능을 비활성화합니다.
서명자가 목적 전송을 제출하면 계약은 중복 지출 여부를 확인하고 challengeableTransfers 배열에 저장합니다. objectiveTransfer() 호출에 대한 초기 중복 지출 검사는 주소의 최종 잔액에 대해서만 확인합니다. 프로토콜은 또한 cleanChallengeWindow()가 호출될 때 중복 지출을 다시 확인합니다[아래 참조]. 여기서 모든 챌린지 가능한 전송의 총 지출 금액이 결합되어 최종 잔액과 비교됩니다. 활성 챌린지 기간이 끝나면 핵심 계약이 전송을 최종화할 수 있습니다. 모든 주소가 cleanChallengeWindow() 메서드를 호출할 수 있으며, 이 메서드는 최종화할 수 있는 모든 챌린지 가능한 전송을 실행하고 삭제하려고 시도합니다. 이 시점에서 전송이 완료됩니다.
모든 주소가 핵심 계약에 challengeAndRecord() 메서드를 호출할 수 있으며, 이 메서드는 하나 이상의 전송을 받아 모든 챌린지 가능한 전송과 함께 중복 지출을 확인합니다. 이 프로세스에서 중복 지출(챌린지 창 기간 동안 한 주소에서 전송된 토큰의 총 금액이 잔액을 초과)이 감지되면 중복 지출 주소에서 시작된 모든 챌린지 가능한 전송을 문제가 있는 것으로 표시합니다. cleanChallengeWindow() 호출 중에 핵심 계약은 문제가 있는 거래를 삭제하지만 실행하지는 않습니다.
이러한 규칙은 다음과 같은 시스템을 만듭니다:
- 하나의 정직한 중계만 필요합니다.
- 중복 지출을 방지합니다.
- 배포 간 합의를 유지합니다.
그러나 이 시점에서 프로토콜은 매우 유용하지 않습니다.
4부: 크로스 체인
3부와 크로스 체인 토큰 사이에는 놀랍도록 작은 격차가 있습니다. 격리된 크로스 배포 솔루션은 계약이 서로 상호작용할 필요가 없기 때문에 각 배포는 다른 배포에 대한 인식이나 연결이 필요하지 않습니다. 그들은 완전히 다른 블록체인에 있을 수 있고 프로토콜은 여전히 작동할 것입니다. 우리는 연결하고자 하는 각 네트워크에 하나의 인스턴스를 배포할 수 있습니다. 그런 다음 주소가 한 체인에서 전송을 시작하면 중계가 모든 다른 체인에 복제할 것입니다.
신뢰할 수 없는 교환 계약은 프로토콜을 더 익숙한 형태로 재포장합니다. 여기서 EOA 주소는 한 체인에서 다른 체인으로 자산을 전송할 수 있습니다. 이는 스왑-동기화-스왑오프 모델을 활용하여 작동합니다:
- 소스 체인에서 이더리움 기반 토큰을 크로스 체인 토큰으로 스왑합니다.
- 중계가 크로스 체인 잔액을 동기화할 때까지 기다립니다.
- 크로스 체인 토큰을 이더리움 기반 토큰으로 스왑합니다.
그러나 유니스왑과 같은 표준 유동성 풀은 이더리움 기반 토큰을 크로스 체인 토큰으로 스왑할 수 없습니다. 전통적인 모델에 의존하는 대신 주문장부와 유사한 접근 방식을 취해야 합니다.
판매자의 경우:
- 거래 가격 수준을 지정하여 이더리움 기반 토큰을 교환 계약에 예치합니다.
- 구매자가 주문을 이행할 때까지 기다립니다.
구매자의 경우:
- 지정된 가격 수준에 대한 미이행 거래를 가져옵니다.
- 적절한 판매자에게 크로스 체인 토큰을 전송하는 거래와 서명을 생성합니다.
- 거래와 서명을 교환 계약에 보내면 계약이 이를 확인합니다.
