tl;dr

  • L2는 기반이 되는 L1과 동일한 검열 저항성을 가져야 합니다.
  • BOB에서 사용자는 이미 이더리움 트랜잭션을 통해 BOB에서 이더리움으로 자산을 강제 출금할 수 있습니다.
  • BOB는 BitVM 브릿지의 경우, 사용자가 BOB에서 거래를 집행할 수 있는 방법으로 비트코인을 통합하기 위해 노력하고 있습니다.
  • 비트코인 사용자는 BOB에 트랜잭션을 전송하지 않고도 BOB에서 BTC를 출금할 수 있습니다.

‍

L2의 핵심 속성 중 하나는 시퀀서가 오프라인 상태일 때에도 상태가 계속 진행되어야 한다는 것입니다. L2는 L2의 온라인 상태와 무관하게 업데이트할 수 있는 데이터 가용성(DA) 계층에서 상태를 읽고 쓰는 방식으로 이를 달성합니다. 이렇게 하면 시퀀서가 오프라인 상태이거나 시퀀서가 트랜잭션을 직접 수락하지 않을 때에도 사용자가 트랜잭션을 강제로 포함시킬 수 있습니다.

BOB의 BitVM 브리지의 경우, 이는 흥미로운 문제를 제기합니다. BOB는 현재 이더리움 EIP-4844 블롭을 DA 레이어로 사용합니다. 이더리움 사용자는 BitVM 브릿지를 통해 비트코인으로 쉽게 출금을 트리거할 수 있습니다. 하지만 이를 위해서는 사용자가 이더리움에 이더를 보유하고 있어야 합니다.

이는 저희에게는 충분하지 않습니다: 비트코인 사용자가 BOB에서 비트코인으로 BTC를 강제로 인출하려면 비트코인 상의 BTC만 있으면 됩니다. 저희는 이더리움을 DA로 기본 설정하는 동시에 사용자가 비트코인에서 특별 거래를 통해 BOB에 거래를 강제로 포함할 수 있도록 하는 하이브리드 솔루션을 개발 중입니다. 이 블로그 게시물에서 진행 중인 작업을 공유해드리게 되어 기쁩니다.

‍

DA 및 파생에 대한 배경

BOB의 전체 L2 상태는 L1과 DA 레이어에서 구성해야 하기 때문에 파생 과정은 L2에게 매우 중요합니다. 이를 통해 L2는 DA 레이어(이더리움의 경우)와 동일한 검열 저항성을 누릴 수 있습니다.

간단히 설명하자면, 롤업(특히 OP 스택 체인)에서는 L1에 두 가지 유형의 데이터가 있습니다:

  • 입금 거래 "옵티미즘 포털" 컨트랙트에 이루어진 거래입니다. 이는 일반적으로 이더리움 사용자가 BOB에 자산을 예치하기 위해 수행하는 트랜잭션입니다. 이러한 입금 트랜잭션은 BOB에서 다른 트랜잭션을 실행하는 데에도 사용할 수 있습니다.
  • L2 트랜잭션에서 시퀀서(또는 더 정확하게는 작업배처)가 제출한 배치입니다. 여기에는 BOB에서 사용자가 직접 작성한 모든 트랜잭션이 포함되며, 결국 이더리움 블록에 다시 포함됩니다.

‍

DA 레이어로서의 비트코인

비트코인을 DA 레이어로 사용하려면 왜 비트코인을 완전히 DA 레이어로만 사용하도록 완전히 전환하지 않을까요? 답은 대부분 비용입니다. 비트코인은 사용 가능한 저장 공간이 매우 적기 때문에(대략 10분마다 약 4MB) 저장 비용이 높습니다.

그러나 BOB의 경우 이더리움을 전체 거래 데이터를 게시하는 "메인" DA 레이어로 사용하되, 이더리움 DA를 사용할 수 없는 경우 검열에 강한 비트코인을 폴백 레이어로 추가할 수 있습니다. 기본적으로 이더리움은 낙관적인 DA 레이어가 되고 비트코인은 비싸지만 장애에 강한 최후의 수단이 됩니다.

‍

하이브리드 파생 파이프라인

기본적인 해결책은 BOB에 비트코인을 파생 파이프라인의 일부로 추가하여 BOB(특히 "연산 노드")가 이 순서대로 입력을 처리하도록 하는 것입니다:

  1. 비트코인 강제 출금 거래(BOB 전용으로 새로 추가됨)
  2. BOB의 옵티미즘 포털 계약(OP 스택 표준)에 대한 이더리움 예치금
  3. 옵배처의 이더리움 배치(OP 스택 표준)

비트코인 강제 인출 트랜잭션을 BOB 파생 파이프라인으로 인코딩하는 가능한 솔루션을 살펴보겠습니다. 이 방법은 아직 연구 중이므로 변경될 수 있다는 점에 유의하시기 바랍니다.

‍

비트코인 강제 출금 거래

강제 출금 거래를 생성하려면 세 가지 부품이 필요합니다:

  1. 비트코인에서 강제 출금 트랜잭션을 구성합니다.
  2. 강제 출금 거래를 비트코인의 크기 한도 내에서 비트코인에 저장합니다.
  3. 비트코인 강제 출금 거래에 대한 가스 비용을 처리합니다.

‍

1. 강제 출금 트랜잭션 구성하기

OP 스택 입금 거래의 구조는 다음과 같습니다:

  • bytes32 sourceHash: 입금 출처를 고유하게 식별하는 소스 해시입니다.
  • 발신자 주소: 발신자 계정의 주소입니다.
  • 주소입니다: 수취인 계정의 주소 또는 입금된 거래가 컨트랙트 생성인 경우 널(0 길이) 주소입니다.
  • uint256 mint: L2에서 발행할 ETH 값입니다.
  • uint256 값입니다: 수신자 계정으로 전송할 ETH 값입니다.
  • uint64 가스: L2 트랜잭션의 가스 한도입니다.
  • bool isSystemTx: true이면 트랜잭션이 L2 블록 가스 풀과 상호작용하지 않습니다.
  • 바이트 데이터: 호출 데이터입니다.

강제 출금 트랜잭션은 입금 트랜잭션의 데이터 필드에 인코딩된 출금 트랜잭션을 포함해야 합니다. 이는 BOB에서 비트코인으로 인출을 트리거하는 트랜잭션을 생성하는 방식으로 이루어지며, 트랜잭션이 이더리움에서 전송된 경우와 동일하게 작동합니다.

그런 다음 위의 모든 데이터가 포함된 강제 출금 거래의 (압축된) 버전을 비트코인에 저장할 수 있습니다.

‍

2. 비트코인에 강제 출금 거래 저장하기

강제 출금 트랜잭션의 데이터는 일반적으로 OP_RETURN 출력에 저장해야 하는 것보다 크므로, 데이터를 저장하는 데 탭루트 출력을 사용할 가능성이 높습니다.

이더리움에서 입금 거래(출금이 포함될 수 있음)는 BOB의 옵티미즘 포털 컨트랙트로 전송되기 때문에 쉽게 식별할 수 있지만, 비트코인에서 강제 출금 거래를 식별하는 것은 쉽지 않습니다.

데이터 직렬화: 강제 출금 트랜잭션은 "봉투" 구조 내에서 탭루트 스크립트를 사용해 직렬화됩니다. 이는 비트코인 네트워크의 노프이며, 예를 들어 오디날에도 사용됩니다. 저희는 필요에 따라 구조를 조정합니다.

Unset

OP_FALSE OP_IF

 OP_PUSH "bob"

 OP_1

 OP_PUSH "트랜잭션"

 OP_0

 OP_PUSH $WITHdrawal_transaction_data

OP_ENDIF

2단계 커밋/공개 체계:

오디널과 마찬가지로, 사용자는 비트코인에 두 개의 트랜잭션을 제출해야 합니다:

  • 트랜잭션 커밋: 비문 콘텐츠가 포함된 스크립트에 커밋하는 탭루트 출력을 생성합니다. 이 트랜잭션은 아직 데이터를 공개하지 않으며, BOB 풀 노드와 시퀀서가 인출 트랜잭션을 포함하려면 두 번째 트랜잭션이 필요합니다.
  • 트랜잭션 공개: 트랜잭션 공개: 커밋 트랜잭션의 출력을 사용하여 비문을 온체인에 공개합니다. 즉, BOB에 포함하기 위해 사용자의 출금 트랜잭션을 공개합니다.

‍

3. 강제 출금 거래에 대한 가스 비용 처리하기

이 문제는 현재 두 가지 옵션이 고려되고 있는 가장 열린 문제입니다:

  • 비트코인에서 강제 인출 거래에 대해 가스를 0으로 설정하고 BOB에 있는 사용자의 이더리움 잔액에서 가스 비용을 차감합니다. 이렇게 하면 BOB에 이더를 보유한 사용자만 강제 출금할 수 있습니다. 그러나 이 방법은 사용자가 강제 출금하려면 BOB에 이더리움이 있어야 하며, 비트코인에 BTC를 보유한 사용자는 강제 출금할 수 없으므로 좋은 옵션은 아닙니다.
  • 가스는 사용자가 비트코인에서 BTC로 지불합니다. BOB 네트워크는 비트코인에 BTC를 받을 수 있는 주소가 있어야 하며, 사용자가 받은 BTC를 BOB에서 이더로 효과적으로 교환하여 가스 비용의 L1 부분과 실행 비용을 지불할 수 있어야 합니다. 이 옵션은 BOB 게이트웨이를 사용하고 BOB DAO의 EVM 주소를 BTC 수신자로 설정하는 것입니다.

또한 더 많은 아이디어를 실험하고 있으니 더 많은 업데이트를 기대해주세요!

‍

모든 것을 한데 모으기

누구나 비트코인과 이더리움의 데이터만 확인하면 BOB의 상태를 확인할 수 있습니다:

  1. 비트코인에서 모든 출금 트랜잭션을 읽습니다. 이는 각 인출에 대해 두 개의 트랜잭션, 즉 하나의 커밋 트랜잭션과 하나의 공개 트랜잭션으로 인코딩됩니다. 이것이 바로 저희가 운영 스택에 추가하는 기능이며 파생 파이프라인을 개선하는 부분입니다.
  2. 이더리움에서 BOB의 옵티미즘 포털 컨트랙트에 이루어진 모든 트랜잭션을 읽어보세요. 이는 이미 표준 OP 스택 파생 파이프라인의 일부입니다.
  3. BOB에서 직접 생성된 모든 트랜잭션을 읽고 이더리움에서 배치의 일부로 통합합니다. 중요한 점은 풀 노드가 시퀀서에서 직접 읽지 않고 이더리움 블롭에서 읽어서 확정 트랜잭션을 수신한다는 것입니다. 이는 이미 표준 OP 스택 파생 파이프라인의 일부입니다.

‍

기술적 과제

데이터 일관성: 이더리움과 비트코인 체인 간의 데이터 일관성을 보장하는 것은 중요하지만, 단순히 두 체인에 트랜잭션 데이터가 존재한다고 해서 유효성이 보장되는 것은 아닙니다. 트랜잭션은 롤업의 상태 전환 함수에 따라 유효한 상태 전환을 나타내야 합법적인 것으로 간주됩니다. 이를 위해서는 트랜잭션을 수락하기 전에 먼저 유효한 상태 변화를 초래하는지 확인하는 검증 로직을 운영 노드(또는 다른 합의 계층 구현) 내부에 구현해야 합니다.

사기 증명과 유효성: BitVM과 이더리움의 사기 증명 시스템은 두 체인의 데이터를 모두 처리할 수 있도록 개선되어야 하며, 이는 분쟁 해결을 더욱 복잡하게 만들 수 있습니다. 이를 해결하기 위해서는 비트코인과 이더리움에서 발생할 수 있는 거래를 정확하게 파악하여 BitVM 브릿지와 BOB의 이더리움 정산에 반영해야 합니다.

스토리지 증가: 또한 네트워크의 BOB 노드는 비트코인과 이더리움의 데이터를 처리하고 저장해야 하기 때문에 스토리지와 대역폭 요구량이 증가합니다. 그러나 비트코인에서 이루어진 BOB 트랜잭션이 최신 비트코인 블록을 참조하는 이더리움 블롭에 포함되도록 요구함으로써 이를 완화할 수 있습니다. 이렇게 하면 노드는 최근 비트코인 블록만 동기화하면 됩니다.

‍

다음 단계

저희는 비트코인의 보안과 이더리움의 혁신을 결합한 하이브리드 롤업의 지평을 넓히게 되어 기쁩니다. 이 구체적인 문제에서 저희는 비트코인의 거래 검열 저항성을 BOB의 롤업 스택과 결합하는 데 관심을 두고 있습니다. 진행 상황에 따라 더 많은 정보를 이 블로그 게시물에 업데이트할 예정입니다.

‍