OP-Stack: 블록체인을 구축하기 위한 가장 간편한 프레임워크

Key Takeaways

• 자체 블록체인 또는 롤업을 만드는데 커스터마이징, 확장성연관 툴 등을 고려했을때 분명한 OP-Stack은 가장 배포하기 쉬운 소프트웨어다.

• OP-Stack의 아키텍쳐를 보면 총 4개의 요소와 다수의 컨트랙트로 구성되어 있다

• Coinabse의 Base을 포함해 다양한 롤업과 인프라 툴이 OP-Stack에서 구축되고 있다.

• 그러나 OP-Stack에는 Fault-proof 시스템, 중앙 집중화 및 블록체인 코어 개발에서 한계가 있다.

• 결론: OP-Stack은 개인 롤업을 보다 간단하게 생성할 수 있게 하며 생태계의 성장과 맞춤형 롤업 공간의 혁신을 위한 토대를 마련할 것이다.

1. OP-Stack으로 블록체인 만들기

탈중앙화 어플리케이션(dApp)이 계속 성장하고 더 많은 기존 비즈니스가 블록체인에 참여하기 시작하면서 분명한 추세가 나타나고 있다. “자체 블록체인 또는 롤업 구축에 대한 관심이 높아지고 있다.” 자체 블록체인을 구축하면 몇 가지 주목할 만한 이점을 얻을 수 있거 이 과정에서 얻을 수 있는 이점과 OP-Stack을 사용해야하는 이유는 다음과 같다:

1.1 커스터마이징 가능성

커스터마이징 측면에서 자신만의 롤업 또는 블록체인을 생성하면 다양한 기능을 사용에 맞게 추가할 수 있다. 거버넌스 모델, 트랜잭션 수수료, 스마트 컨트랙트의 기능 등 특정 요구사항에 맞게 이러한 요소를 네트워크에 내재하여 운영할 수 있다.

OP-Stack의 설계시 중요하게 고려된 모듈성(Modularity)은 커스터마이징을 장려한다. 배포시 특정 컨트랙트들을 내장시켜 사용자들이 사용할때 더 더 통일성있는 규격과 낮은 비용으로 사용할 수 있으며 인프라단에서는 실행 클라이언트와 같은 구성 요소를 다양화할 수 있도록 의도적으로 적응성을 고려한 구조로 설계되었다.

1.2 확장성

롤업과 블록체인은 근본적으로 확장성 문제를 해결하도록 설계되었다. 자체 솔루션을 출시하는 작업을 수행할 때, 리소스를 체인의 주 사용원에 국한하여 사용되기에 낮은 비용으로 높은 트랜잭션 처리량을 안정적으로 처리할 수 있다. 이를 통해 리소스를 공유해야하는 기존 플랫폼이 제공하는 수준을 뛰어넘는 수준의 확장성을 구현할 수 있다.

1.3 리소스 효율성

OP-Stack은 데이터 가용성 계층의 보안 기능을 활용할 수 있으며, 단일 시퀀서로 운영할 수 있다. 코스모스나 폴카닷에서 제공하는 전문 SDK는 상호운용성 솔루션과 다양한 핵심 기능 커스터마이징 등 다양한 이점을 제공하지만, 별도의 검증자 세트를 운영하거나 공유 보안 자산을 활용하기 위해 포함해야 하는 등 높은 비용이 발생한다. 또한 이더리움 생태계에 비해 개발 도구가 풍부하지 않지만 반대로 OP-Stack은 이더리움 생태계에서 사용 가능한 도구를 활용할 수 있으며, 이더리움과 같은 기본 데이터 가용성 계층의 보안 기능을 활용할 수 있다.

2. OP-Stack 소개

OP-Stack은 옵티미스틱 롤업을 구축을 할 수 있도록 제공되는 오픈소스 코드다. 이는 2023년 6월 6일 옵티미즘의 중요한 변화 기점인 베드락 업그레이드 이후로 메인넷에서 사용되고 있다. 옵티미즘 네트워크는 베드락 업그레이드를 통해 트랜잭션 수수료를 낮추고 보안을 강화했으며, 더 많은 기능을 제공했다. 주요 개선 사항은 다음과 같다.

베드락 업그레이드를 통해 옵티미즘 메인넷의 프로토콜 비용이 47% 감소했다. 일괄 압축을 최적화여 데이터 가용성을 위해 이더리움에 데이터를 저장하는 비용을 줄임으로써 수수료가 감소했다. 전체적으로 스테이트 체인 커밋먼트가 99%, 일괄 제출 비용이 20%로 감소될 것으로 예상된다. 향후 OP-Stack은 옵티미즘을 상호 연결된 블록체인의 '슈퍼체인(Superchain)'으로 발전시켜 OP-Stack 기반 체인이 공유 인프라로 상호 연결될 수 있도록 하는 것을 목표로 하고 있다.

3. 아키텍쳐

3.1 구성 요소

OP-Stack 솔루션은 네 가지 요소로 구성되어 있다: 노드(op-geth, op-node) 및 시퀀서별 구성 요소(op-batcher, op-proposer). 각각은 롤업 인프라를 운영하는데 고유한 역할을 한다.

노드:

• op-geth는 주요 트랜잭션 프로세스에서 실행 및 처리 부분을 담당하며 사용자 트랜잭션을 전달받아 효율적인 네트워크 트랜잭션을 보장한다. 또한 op-geth는 트랜잭션에 따라 L2의 상태를 변경시켜 이전 상태에 트랜잭션을 적용하여 새로운 상태를 생성한다. 이러한 트랜잭션은 L1 혹은 L2의 유저들에 의해 발생된다.

• op-node 구성 요소는 표준 이더리움 엔진 API를 통해 데이터 가용성 레이어(현재 옵티미증에서는 이더리움)의 원시 데이터를 실행 레이어를 위한 처리된 입력으로 변환하는 과정을 담당한다. 이 컴포넌트는 이더리움 블록 데이터, 시퀀서 트랜잭션 배치, 예치된 트랜잭션 이벤트 데이터를 입력으로 받으며, op-node 는 이 데이터를 받아 op-geth 에서 활용할 수 있게 가공한다. 이 메커니즘은 효율적이고 정확한 데이터 처리를 보장하기 위해 여러 안전 장치가 마련되어 있다. 이러한 데이터를 가공해서 L2에 활용되는 예시는 다음과 같아. L2 입출금 트랜잭션의 L1 제출, 실패한 트랜잭션 재시도, L2 트랜잭션 상태 업데이트, 최근 팁에 기반한 L1 가스 가격 계산 등의 기능이 있다.

시퀀서별 구성 요소:

• op-batcher는 주로 데이터 가용성 레이어(이더리움)에 트랜잭션 저장을 담당하며, 트랜잭션을 압축하여 네트워크 효율성을 최적화하고 데이터 전송 및 저장을 간소화한다.

• op-proposer는 상태 전환을 마무리하는 데 매우 중요하다. op-geth가 상태를 수정한 후, op-proposer는 트랜잭션 후 상태에 대한 커미션을 L1에 작성하여 업데이트된 상태를 기록한다. 이는 업데이트된 상태의 새로운 머클 루트를 제안하며, 머클 루트를 활용하여 L1에 기록되는 데이터를 최소화하여 트랜잭션 비용을 줄인다. 이러한 상태 루트 제안은 L1 네트워크의 L2OutputOracle에 게시됩니다. 이러한 출력 제안은 권한을 얻기 전에 7일간의 결함 이의 제기 기간을 거쳐야 하며, 잠재적인 분쟁과 이의를 용이하게 하여 네트워크 신뢰성과 책임성을 향상시킨다.

3.2 스마트 컨트랙트

OP-Stack 롤업 운영을 위해서는 여러 개의 컨트랙트를 배포해야 한다. 주요 컨트랙트 중 주요 컨트랙트는 다음과 같다:

3.2.1 OptimismPortal (L1에 배포)

OptimismPortal은 L1과 L2 간의 통신을 용이하게 하는 컨트랙트이다. 이는 옵티미즘 시스템 내에서 크로스 체인 메시징을 위한 기본 게이트웨이 역할을 한다.

이 컨트랙트는 몇 가지 중요한 기능을 지원한다. 첫째, L2에서 실행될 예정인 L1 트랜잭션을 예치하여 L2에서의 실행을 보장 받을 수 있으며 L2 인출을 확인하고 L1에서 자금을 인출하는 역할을 한다. 그리고 가디언(입출금을 일시 중지할 수 있는 주소)에서 관리하는 크로스 체인 메시징을 일시 중지하는 기능이 내장되어 있다. 마지막으로, 확인된 출금과 l2Sender를 추적하여 출금 완료를 용이하게 한다.

또한, L2OutputOracle과 SystemConfig 컨트랙트는 이 컨트랙트와 상호 작용을 한다. L2OutputOracle은 L2 상태의 유효성을 검사하는 데 도움을 주고, SystemConfig 컨트랙트는 시스템 매개 변수를 설정하는데 활용된다.

3.2.2 L2OutputOracle (L1에 배포)

L2OutputOracle은 op-proposer가 제출한 대로 L2의 결과 상태 루트를 보유하는 컨트랙트이다. 이 컨트랙트를 통해 다른 L1 컨트랙트는 L2 상태와 관련된 정보를 인증할 수 있다.

이 컨트랙트는 몇 가지 주요 기능을 지원한다. op-proposer는 특정 제출 간격에 따라 새로운 L2 결과물을 제출할 수 있다. 또한, 챌린저는 유효하지 않은 L2 출력을 제거할 수 있 수 있으며 다른 컨트랙트가 L2 출력을 확인하여 L2 상태에 대한 정보를 검증할 수 있도록 허용한다. 마지막으로, L2 블록 시간을 기반으로 L2의 타임스탬프와 블록 번호를 계산할 수도 있다.

본질적으로 L2OutputOracle 컨트랙트는 L1 컨트랙트에 대한 L2 체인 상태에 대한 신뢰할 수 있는 정보 소스 역할을 한다. L2 상태에 대한 정보을 저장함으로써 L1에 저장되어 있는 L2 트랙잭션을 확인하여 변화를 검증할 수 있다.

3.2.3 L1Block (L2에 배포)

L1Block은 가장 최근에 알려진 L1 블록에 대한 정보를 보관하는 컨트랙트이다.

이 컨트랙트는 L2 컨트랙트에 대한 최신 L1 블록에 대한 결정적인 정보를 제공한다. 이 데이터를 L2에 보관함으로써 L2 콘트랙트는 크로스체인 호출 없이도 L1에 대한 세부 정보에 접근할 수 있다. 저장된 정보는 다양한 방식으로 사용될 수 있다:

• L2 트랜잭션에 대한 L1 가스 가격을 계산할 수 있다.

• 시퀀서가 제출한 L1 블록 데이터를 검증하는 데 활용된다.

• L2 컨트랙트가 특정 L1 트랜잭션이 성공적으로 채굴되었는지 확인할 수 있다.

시퀀서는 새로운 L1 블록이 확정 상태에 도달할 때마다 컨트랙트의 값을 새로 고치는 예금자 주소를 관리한다.

더 많은 컨트랙트는 이 링크에서 확인할 수 있다.

3.3 주요 프로세스

3.3.1 트랜잭션

트랜잭션은 L1(이더리움)에 기록되어야 한다. 일반적으로 op-batcher가 L2 트랜잭션에 대해 이 프로세스를 처리하지만, 모든 사용자는 op-batcher를 우회하는 L2 트랜잭션을 제출하기 위해 L1 트랜잭션을 전송할 수 있다.

그런 다음 상태를 수정하려면 op-geth에 의해 트랜잭션이 실행되어야 한다. 그 후 op-proposer가 트랜잭션 후 상태에 대한 커미션을 생성하고 이를 L1에한다. 한 가지 주목할 점은 op-proposer가 모든 상태 전환 후에 커미션을 생성할 필요는 없다는 것이다.

L2 트랜잭션의 프로세스에는 몇 가지 주요 단계로 실행된다:

L1에 저장

먼저 트랜잭션이 L1에 기록된다. 여기에는 압축과 L1에 게시하는 두 가지 하위 단계가 포함된다. 압축하는 동안 op-batcher는 압축률을 최대화하기 위해 시퀀서 배치를 채널로 나눈다. 채널이 채워지거나 시간이 초과되면 채널이 압축되고 저장된다.

압축 후 트랜잭션은 L1에 배치로 묶여 저장된다. 채널이 포화 상태가 되면 데이터 크기에 따라 단일 또는 여러 개의 L1에 전송된다. L2 트랜잭션은 unsafe(처리되었지만 아직 L1에 기록되지 않음), safe(처리되어 L1에 기록되었지만 L1 재구성으로 인해 삭제될 수 있음), finalized(시간이 오래 지난 L1블록에 기록됨)의 세 가지 상태를 가질 수 있다. 트랜잭션이 finalized 상태에 도달하면 취소할 수 없다.

실행

상태 처리(state processing) 단계에는 기존 상태에 트랜잭션을 적용하여 새로운 상태를 생성하고, 상태를 나타내는 새로운 머클 루트를 제안하는 두 가지 주요 단계가 포함된다. 이 작업은 두 가지 구성 요소에 의해 수행된다: op-geth와 op-proposer이다. 초기 단계에서 op-geth는 트랜잭션을 현재 상태에 적용한다. 이 작업은 트랜잭션이 적용됨에 따라 변경된 상태를 초래한다. op-geth 는 이더리움 geth의 최소한의 수정으로 만들어졌다.

변경된 상태 루트 제안

다음 단계에서는 op-proposer가 개입하여 상태의 새로운 머클 루트를 제안하고, 이 루트를 L1의 L2OutputOracle 컨트랙트에 저장한다. 크기가 커서 집약된 전체 상태를 L1에 직접 기록하는 대신, 머클 루트가 압축된 표현으로 사용된다. 이 루트는 상태 변경에 대한 중요한 정보를 갖고 나타내며 효과적인 검증을 가능하게 한다.

3.2.2 블록 생성

베드락 업그레이드 이전에는 각 트랜잭션에 대해 하나의 블록이 생성되었었다. 그러나 업그레이드 후에는 2초마다 블록이 생성되며, 이 기간 동안의 트랜잭션과 변경된 상태 루트가 블록에 포함된다. 또한 모든 블록에는 L1 블록의 최신 정보를 L1 속성 예치 트랜잭션(L1 Attributes Deposited Transaction)이라는 시스템 트랜잭션으로 매 블록에 기록한다. 그런 다음 op-geth가 트랜잭션을 실행하여 이전 상태를 변경한다.

L1 속성 예치 트랜잭션은 두 가지 중요한 역할을 한다. 첫째, L2 컨트랙트에 가장 최근의 L1 블록에 대한 최신 업데이트를 제공하여 별도의 크로스 체인 호출이 필요 없게 한다. 둘째, L2 콘트랙트가 시퀀서가 제공한 L1 블록 관련 정보의 정확성을 인증할 수 있게 해준다.

L1 블록의 op-node는 블록 파생 중에 이를 생성한다. 이 트랜잭션에는 L1 블록 번호, 타임스탬프, 기본 수수료, 해시 및 기타 관련 세부 정보를 포함한 중요한 정보가 포함되어 있다. L1 속성 예금자 계정에서 생성되며, 이더리움 가치를 포함하지 않고 L2 가스 풀과 상호 작용하지 않으며 유효성에 관계없이 원활한 블록 구성을 보장하기 위해 항상 블록에 포함된다. L1 속성 사전 배포 컨트랙트는 이 정보를 저장하고 액세스할 수 있도록 하는 역할을 담당한다.

L1 속성 예치 트랜잭션의 표준 프로세스는 다음과 같다:

• op-node는 L2 블록에 가장 최근의 L1 블록 정보를 포함하는 L1 속성 예치 트랜잭션을 생성한다.

• 이 트랜잭션은 L2에서 수행되고, L1 속성 사전 배포된 컨트랙트를 시작한다.

• 사전 배포된 컨트랙트는 L1 블록 데이터를 보유하고 이벤트를 트리거한다.

• 이제 다른 L2 컨트랙트는 사전 배포된 컨트랙트와 연동하여 최신 L1 블록 정보를 가져올 수 있다.

4. 관련 프로젝트

4.1 OP-Stack 체인

OP-Stack 출시와 함께 이의 코드베이스를 사용하여 롤업을 구축하는 여러 프로젝트가 있다. 코인베이스의 Base, Zora의 체인, BNB의 opBNB가 그 예이며 현재 테스트넷 단계에 있다. 앞으로 더 많은 도구와 실험이 이어질 것으로 보이며 다음은 몇 가지 예시이다.

4.1.1 OP-Clave

(Source: Opclave | ETHGlobal)

이더리움은 ECDSA의 일종인 secp256k1만을 지원한다. 그러기에 다른 타원 곡선의 검증은 새로 배포된 스마트 컨트랙트를 통해 처리해야 하므로 결과적으로 상당한 검증 비용이 발생한다.

이 문제를 해결하기 위해 OP-Clave가 도입되었다. 이는 옵티미즘의 Bedrock 표준을 준수하는 사전 컴파일된 컨트랙트로서 "secp256r1 검증자"를 내장한 맞춤형 롤업이다. 이러한 기능을 통해 아이폰을 하드웨어 월렛과 같이 사용 가능하게 만들었으며 페이스 ID 및 터치 ID 검증 트랜잭션을 적용할 수 있는 환경의 기반을 마련했다.

4.1.2 셀레스티아 OP-Stack

(Source: Celestia)

셀레스티아는 셀레스티아를 데이터 가용성 계층으로 사용하여 OP-Stack 기반 롤업을 운영할 수 있는 데모 코드베이스를 공개했다. OP-Stack의 운영 비용 대부분이 이더리움에 트랜잭션을 저장하는 데서 발생한다는 점을 고려할 때, 이 구현을 통해 롤업은 트랜잭션 데이터를 셀레스티아에 저장하고 트랜잭션 데이터에 대한 참조 링크만 이더리움에 저장할 수 있다. 결과적으로 이는 많은 운영 비용 절감으로 이어진다.

4.1.3 OP-Stack을 지원하는 RaaS

롤업을 배포하고 관리할 수 있는 도구를 제공하는 서비스형 롤업(RaaS)은 성장하고 있는 분야이다. Conduit, Caldera와 같은 회사가 OP-Stack을 지원하는 솔루션며 이들 서비스는 롤업의 관리 및 배포를 간소화하여 OP-Stack 애플리케이션의 성장과 개발을 지원한다. 최근에 Zora에서 발표한 롤업도 Caldera를 활용하여 OP-Stack 체인으로 만들어졌다.

4.2 인프라 툴

OP-Stack의 중요한 이점은 이더리움 생태계에서 사용되는 툴링을 활용할 수 있다는 것이다. 이를 통해 다양한 이더리움 툴을 사용할 수 있다. 다른 생태계의 경우 개발 툴 인프라가 부족하기에 개발시 많은 난관이 있다.

(Source: DappCamp)

4.2.1 op-erigon

테스트 인 프로덕트에서 개발한 op-erigon은 op-geth의 대체 실행 클라이언트로, 이더리움의 에리곤을 기반으로 모델링되었다. 현재 op-geth만이 프로덕션에서 사용되는 유일한 실행 클라이언트이다. 하지만 op-erigon 은 첫번째 대체 실행 클라이언트로 메인넷에 배포되었으며, 실행 클라이언트의 다양성을 향상시킬 것으로 기대된다.

4.2.2 Magi

a16z가 개발한 Magi는 롤업 내 클라이언트 다양성을 향상시키기 위한 op-node용 대체 롤업 클라이언트입니다. Rust로 작성된 Magi는 Geth 및 Besu와 같은 실행 클라이언트와 호환됩니다. op-node와 동일한 기능을 공유하지만, 몇 달간의 추가 개발을 통해 이를 대체할 수 있을 것으로 예상된다.

5. 한계

5.1 결함 증명의 한계

옵티미스틱 롤업은 수백만 건의 트랜잭션으로 프로덕션 환경에서 광범위한 테스트를 거쳤다. 그러나 입력 데이터(트랜잭션)를 저장하고 값비싼 데이터 가용성 계층에 저장해야 하며, 7일의 파이널리티를 기다리는 것은 너무 길다는 단점이 있다. 이것이 바로 zkEVM이 주목받는 이유이다. 최근 OP-Stack에 zk를 구현하기 위한 제안요청서(RFP)가 발표되었지만, 영지식 기술을 OP-Stack에 통합하는 데는 상당한 시간이 소요될 것으로 예상된다. 또한, 현재 결함 증명 시스템에는 소수의 참여자만 참여 가능하기에 효율성과 탈중앙화 모두에서 개선이 필요하다. 하지만 이러 결함 증명 시스템은 다음OP-Stack의 다가오는 마일스톤에서의 주 과제이기에 가까운 미래에 상당한 진전이 있을 것으로 예상된다.

5.2 탈중앙화

현재 OP-Stack 시스템의 주요 단점 중 하나는 시퀀서의 중앙 집중화이다. 시퀀서는 단일 주체에 의해 운영되며, 베드락 업그레이드 이후에는 트랜잭션당 블록이 아닌 2초마다 블록이 생성되므로 프런트 러닝과 같은 사용자들에게 피해가 가는 MEV가 발생할 가능성이 있다. 현재 멤풀은 이를 방지하기 위해 프라이빗으로 유지되고 있다. 그러나 옵티미즘 팀은 로드맵에 탈중앙화 계획을 가지고 있으며 공유 시퀀서 등이 개발 되고 있기에 추후에는 탈중앙화를 달성할 수 있을 것으로 보인다.

5.3 블록체인 코어 개발의 한계

이더리움 생태계는 활발한 개발자 커뮤니티를 갖고있지만, 네트워크 코어 측면의 실험은 미미하다. 애플리케이션에 특화된 코어 변경 대신 대부분의 구현된 기능은 보다 일반화되어 있다. 특정 애플리케이션에 필요한 이더리움 개선 제안(EIP)은 이더리움 코어 업그레이드에 포함되기 어려운 경우가 많다. 따라서 이러한 구현은 대부분 스마트 콘트랙트 측면에서 이루어진다. 이러한 상황은 옵티미즘 생태계에도 적용된다.

6. 결론

OP-Stack은 자체 롤업을 쉽게 구축할 수 있는 길을 열었으며, 수많은 프로젝트가 이 생태계 내에서 구축되고 있다. 생태계가 계속 성장하고 번창함에 따라 롤업 배포는 스마트 컨트랙트를 배포하는 것만큼이나 간단해질 것이다.

필자 의견으로 스마트 컨트랙트만으로 애플리케이션을 구축하는 데는 분명한 제약이 있다. 스마트 컨트랙트 기반 디앱에서 무수히 많은 혁신과 실험이 이루어지고 있지만 분명한 한계가 있으며 맞춤형 롤업 및 블록체인 구축을 하는 인프라에 있어 더욱 흥미로운 발전이 이루어질 것이라고 생각한다. 이는 OP-Stack과 같은 프레임워크 덕분에 가능해지고 있으며 많은 프로젝트들이 다양한 시도를 하고 있는 만큼 앞으로 1년동안 많은 발전이 있을 것이다.

이 글의 비주얼을 제공해주신 Kate에게 감사의 말씀을 전합니다.