Google Cloud가 참여하다, Puffer UniFi가 Based Rollup의 마지막 1마일을 메울 수 있을까?

한 Web2 대기업의 진입이, 이전에는 주로 기술적 맥락에서만 존재하던 ‘Gateway’라는 새로운 개념을 대중의 시야로 끌어올렸습니다.

9월 22일, Puffer는 Google Cloud와 협력을 발표했습니다. Google Cloud는 핵심 인프라 파트너로서 Puffer Preconf를 통해 Gateway를 운영하고, Puffer UniFi의 실행 레이어를 지원하며, 트랜잭션 처리를 돕고, 트랜잭션이 최종적으로 이더리움에 정산되기 전에 Execution Preconfirmation을 제공할 예정입니다.

더 주목할 만한 점은 Puffer UniFi가 Google Cloud Gateway를 사용하는 첫 번째 Rollup이 된다는 것입니다.

하지만 이것을 단순히 ‘또 하나의 Web2 거대 기업이 Web3에 진입했다’고 이해한다면, 이번 협력 뒤에 숨은 더 논의할 가치가 있는 부분을 놓칠 수 있습니다.

Google Cloud가 이번에 맡은 역할은 전통적인 의미에서 블록체인 프로젝트에 컴퓨팅 파워, 노드 호스팅 또는 클라우드 서비스를 제공하는 주변부 역할이 아니기 때문입니다. 오히려 그것은 Puffer UniFi의 실시간 실행 아키텍처에 직접 진입하여, 트랜잭션 처리, Preconfirmation과 최종 이더리움 정산을 연결하는 Gateway 레이어 중 하나가 되고 있습니다.

이것은 또한 더 큰 질문을 제기합니다: Puffer UniFi는 도대체 무엇을 구축하고 있는가? 왜 Gateway가 필요한가? 그리고 Google Cloud는 왜 이 비교적 저층의 위치에서 이더리움에 진입하기로 선택했는가?

그 답은 아마도 이더리움 L2가 진입하고 있는 새로운 단계에서 시작해야 할 것입니다.

1. Puffer UniFi: 후반전 Rollup의 하나의 답

2026년에 접어든 후, 이더리움의 Rollup 전략은 분명 미묘한 시점에 놓여 있습니다.

Vitalik Buterin이 L2 경로에 대한 성찰을 촉발한 이래, L2가 이더리움 확장 도구로서 가진 단계적 역사적 사명은 시장과 여론 차원에서 완료되었다고 선언되었습니다.

하나의 질문이 점점 더 날카로워지기 시작했습니다. 즉, L2가 더 이상 단순히 L1의 혼잡 압력을 분담하는 확장 도구가 아닐 때, 그것은 도대체 자신의 존재를 어떻게 정의해야 하는가? 그리고 L1과 어떻게 더 통일된 보안, 정렬, 유동성 및 조합성 관계를 다시 형성해야 하는가?

Puffer UniFi는 그중 하나의 답을 제시하려고 시도하고 있습니다.

Puffer UniFi가 선택한 것은 상대적으로 독립적인 중앙화 정렬 체계를 계속 운영하는 것이 아니라, Based Rollup으로 나아가는 것입니다. 즉, Rollup의 정렬 권한을 더 직접적으로 Ethereum L1에 앵커링하여, 이더리움 검증자 체계가 정렬에 참여하고 궁극적으로 Ethereum 자체의 보안성과 중립성을 계승하도록 하는 것입니다.

이것이 L2가 이미 의미를 잃었다는 것을 뜻하지는 않습니다.

더 정확히 말하자면, 단순한 확장이라는 단계적 임무가 점차 완료됨에 따라, Rollup은 자신의 가치 포지셔닝을 다시 답해야 하기 시작했습니다. 미래에 계속 하나의 범용 실행 레이어로 존재할 것인가, 아니면 더 명확한 애플리케이션, 시나리오 및 사용자 경험을 중심으로 이더리움과 더 긴밀하게 협력하는 애플리케이션 인프라가 될 것인가?

결국 5년 전의 이더리움에게 L2 확장은 매우 현실적이고 매우 성공적인 노선이라고 할 수 있었지만, 5년이 지난 오늘날 자산과 유동성이 수십 개의 독립된 섬에 분산되어 있는 상황에서, Rollup은 재포지셔닝이 필요합니다. 예컨대 Vitalik이 주창한 명확한 애플리케이션 시나리오와 비즈니스 경계를 가진 애플리케이션 체인 지향 같은 것입니다.

Based Rollup의 의미는 바로 이러한 관계를 재조정하려는 데 있습니다.

그 핵심 아이디어는 복잡하지 않습니다. Rollup이 궁극적으로 여전히 이더리움에 의존하여 정산과 보안 검증을 완료한다면, 정렬 권한도 더 직접적으로 이더리움 L1으로 돌아가서 이더리움 검증자 체계가 Rollup 정렬을 담당하게 할 수 있습니다. 그렇다면 이론적으로 Rollup의 단일 정렬자에 대한 의존을 제거할 수 있을 뿐만 아니라, L1과 L2 사이의 동기식 조합성도 진정으로 실현할 수 있습니다.

다시 말해, Based Rollup이 제시하는 것은 ‘더 빠른 L2를 다시 만드는 것’이 아니라, 이더리움 네이티브 노선에 더 가까운 답입니다. 즉, 확장이 더 이상 분열을 의미하지 않도록 하고, L2의 성장이 다시 L1의 보안과 가치에 기여하도록 하는 것입니다.

이것은 이론적으로 거의 흠잡을 데 없는 방향이지만, 문제는 이론상의 최적해가 현실에서 자동으로 사용 가능한 시스템이 된다는 것을 의미하지는 않는다는 점입니다:

• 첫 번째 현실적 제약은 속도입니다. 이더리움 L1의 블록 생성 시간은 약 12초입니다. 만약 Rollup 정렬이 완전히 L1 리듬을 따른다면, 모든 트랜잭션은 상대적으로 신뢰할 수 있는 확인을 얻기 위해 최소한 하나의 L1 블록을 기다려야 합니다. 일반 송금은 아마도 받아들일 수 있겠지만, 즉시 결제, 오더북, 무기한 선물 계약 나아가 고빈도 DeFi 애플리케이션에게는 분명 중앙화 정렬자가 제공하는 서브초 수준의 피드백과 비교할 수 없습니다 (추가 읽기 《Preconfs 진화론: ‘패치’에서 ‘인프라’로, UniFi AVS가 Based Rollup의 게임 규칙에 어떤 영향을 미치는가?》);
• 두 번째 제약은 실행 부담입니다. 잘 알려진 바와 같이 이더리움은 오랫동안 검증门槛을 낮추고 더 많은 일반 하드웨어와 개인 노드가 네트워크 합의에 참여할 수 있도록 하는 데 전념해 왔습니다. 그러나 Based Rollup은 L1 검증자가 고빈도 정렬, 저지연 실행 등의 역할을 직접承担하도록 요구하며, 검증자의 하드웨어, 네트워크 및 운영 유지门槛을 높이는 것을 피할 수 없고, 오히려 실행 레이어에서 새로운 중앙화 압력을 초래할 수 있습니다;
• 세 번째 제약은 인센티브 구조에서 비롯됩니다. 많은 L2 팀에게 Based 아키텍처로 이전하는 것이 기술적 복잡성 증가를 의미하고 동시에 충분한 수익을 얻지 못한다면, 계속 자신의 중앙화 정렬자를 유지하는 것이 여전히 더 합리적인 선택입니다;

따라서 Based Rollup의 문제는 결코 방향이 잘못된 것이 아니라, 진정으로 사용 가능해지기까지 현실 인프라의 한 층이 부족하다는 것입니다. 시스템이 완전히 L1의 12초 리듬에 묶여 있기만 하면 속도를兼顾하기 어렵습니다. 그리고 재중앙화하지 않으면서 메인넷의 중립성을 유지하고 동시에 중앙화 정렬자에 가까운 상호작용 경험을 얻으려면, 실행 레이어에 새로운 역할 분업을 도입해야 합니다.

이것이 바로 Puffer UniFi가 반드시 해결해야 하는 핵심 모순입니다.

Puffer Preconf는 바로 이러한 배경에서 Puffer UniFi의 핵심 기술 스택으로 포함되었습니다. EigenCloud(구 EigenLayer) 위에 구축된 일련의 사전 확인 서비스로서, 정렬 권한은 여전히 Ethereum L1에 앵커링되지만, 고성능 정렬, 저지연 피드백 및 실행 사전 확인을 반드시 모두 L1 Validator가 직접 완료할 필요는 없습니다.

다시 말해, Based Rollup이 Puffer UniFi가 ‘궁극적으로 누구에 의존하여 정렬하고 정산하는가’에 대한 답이라면, Puffer Preconf가 해결하는 것은 ‘최종 정산 이전에 사용자가 어떻게 실시간이고 신뢰할 수 있는 실행 경험을 얻는가’입니다.

그리고 이것이 바로 Gateway를 이해하는 출발점입니다.

2. 실시간 실행: Puffer UniFi는 왜 Preconf가 필요한가?

Gateway를 이해하기 전에, 먼저 Preconfirmation이 도대체 무엇을 약속하는지 이해해야 합니다.

실제로 주류 L2에서 사용자가 트랜잭션 피드백을 빠르게 볼 수 있는 것은, 종종 중앙화 정렬자가 먼저 일종의 soft guarantee를 제공하여 이 트랜잭션이 이미 큐에 들어갔고 프런트엔드도 곧 실행 결과를 표시하여 사용자가 경험상 ‘이미 확인되었다’고 느끼게 하기 때문입니다.

하지만 엄밀히 말하면, 이러한 빠른 피드백은 단일 정렬자에 대한 신뢰에 더 많이 기반을 두고 있습니다.

정렬자가 다운되거나, 지연되거나, 악의적으로 행동하거나, 검열을 겪으면, 이러한 약속은 종종 충분히 강한 경제적 제약과 검증 가능한 책임 메커니즘을 결여합니다. 다시 말해, 전통적인 Rollup의 ‘빠름’은 상당 부분 정렬자 자체의 신용에서 비롯됩니다.

Puffer UniFi에게 이것은 분명 충분하지 않으며, Puffer Preconf가 해결하려는 것이 바로 이 문제입니다.

그것은 ‘빠른 확인’을 단일 운영자에 대한 신뢰에서 경제적 담보, 서명 약속 및 책임 메커니즘에 의해 뒷받침되는 실행 약속으로 끌어올리려고 시도합니다. 이것은 단지 Puffer UniFi를 더 빠르게 만드는 것이 아니라, 이 ‘빠름’을 신뢰할 수 있게 만드는 것입니다.

이 아키텍처를 이해하려면, 그 역할 분업을 명확히 봐야 합니다.

Puffer Preconf의 설계에서 L1 검증자는 여전히 정렬 권한의 최종 원천이며 이더리움 보안성과 중립성의 앵커이지만, 직접 고성능 정렬 시스템을 운영할 필요도 없고 모든 저지연 실행 작업을 직접承担할 필요도 없습니다. 반대로 재스테이킹과 위임 메커니즘을 통해 검증자는 이 부분의 복잡한 작업을 더 전문적인 Gateway에 맡길 수 있으며, Gateway가 이를 대신하여 Sequencing과 Execution Pre-Confirmation을承接합니다.

다시 말해, 실제로 정렬과 사전 확인 책임을承接하는 것은 새로운 역할인 Gateway입니다.

그것은 전통적인 중앙화 Sequencer의 단순한 이름 변경이 아니고, 더욱이 Rollup에 추가로 붙은 ‘가속 플러그인’이 아닙니다. 그것은 오히려 L1 주권 아래에서 정렬과 사전 확인 책임을 위임받은 전문 실행 대리 레이어에 더 가깝습니다:

• 한편으로는 L1 Proposer가 더 고성능의 정렬과 사전 확인 서비스를 제공하도록 돕고;
• 다른 한편으로는 담보, 서명 약속, 슬래싱 및 수익 분배 등의 메커니즘을 통해 자신이 새로운 무제약 중앙화 노드가 되는 것을 방지합니다;

Gateway는 검증자가 직접 고성능 정렬 시스템을 운영할 필요가 없게 하지만, 정렬 권한의 최종 귀속은 여전히 이더리움 L1에 앵커링됩니다.

이것은 또한 Puffer가 Execution Pre-Confirmation을 강조하는 이유를 설명합니다. 단순한 Inclusion Promise가 아니라: Inclusion promise는 이 트랜잭션이 블록에 포함될 것이라고만 약속하지만, Execution Preconfirmation은 ‘이 트랜잭션이 사전에 약속된 상태에 따라 실행될 것인가’라는 문제를 추가로 해결합니다.

이 차이는 고부가가치 온체인 애플리케이션에极其 중요합니다.

무기한 선물 계약 DEX를 예로 들어보겠습니다. 이러한 시나리오에서 사용자가 가장 두려워하는 것은 주문이 블록에 패키징되지 않는 것이 아니라, 패키징되었음에도 최종 체결 가격, 체결 순서 또는 청산 상태가 이미偏移한 것입니다. 이러한 배경에서 Execution Preconf는 사용자가 주문 시 보았던 상태대로 체결되도록 보장할 수 있으며, 추가 슬리피지나 예측할 수 없는 실행 결과를承受하지 않도록 합니다.

같은 논리는 온체인 중앙 지정가 주문장, 기관 주문 흐름, 결제 정산, 대출 청산, 크로스 레이어 실시간 상태 읽기 등의 시나리오에도 적용됩니다. CLOB는 결정론적 실행 순서와 저지연 피드백이 필요하고, 기관 거래는 책임 추적 가능한 상태 약속이 필요하며, 결제와 급여 분배는 예측 가능한 정산 경험이 필요하고, 청산 시스템은 격렬한 시세 상황에서 가능한 한 상태 드리프트를 줄여야 합니다.

물론, 모든 강한 약속은 강한 제약을 수반해야 합니다. Puffer Preconf와 같은 아키텍처에서 Gateway의 신뢰도는 스스로 신뢰할 수 있다고 주장하는 데서 오는 것이 아니라, 자신의 행동에 대해 경제적 결과를 반드시承担해야 한다는 데서 옵니다. 여기에는 적어도 두 층의 제약이 있습니다:

Gateway는 lookahead 스케줄링에 진입하기 위해 담보를 제공해야 합니다. 만약 어떤 Gateway가 자신이 담당하는 윈도우 내에서 요구대로 배치를 제때 L1에 제출하지 않으면, 후속 Gateway가 대신 제출할 수 있고 전자에 대한 슬래싱을 촉발할 수 있습니다;

사용자 관점에서, 사전 확인 약속이 있는 트랜잭션이 최종적으로 이행되지 않으면, 사용자는 서명된 약속 영수증을 이용해 청구하거나 환불을 신청할 수 있습니다;

주의해야 할 점은 구체적인 슬래싱 메커니즘은 네트워크 단계와 구현 버전의 진화에 따라 변화하므로, 더 정확한 표현은 ‘Gateway가 이미 모든 시나리오에서 slashing되고 있다’가 아니라, Puffer Preconf의 설계 방향은 담보, 보상, 처벌 및 서명 책임으로 전통적인 중앙화 정렬자 아래의 제약 부족한 소프트 약속을 대체하는 것이라는 점입니다.

기술 아키텍처 외에도, 또 하나 피할