이 기사에 대한 소식을 퍼뜨리고 싶으시다면 이 스레드 에 참여해 주시기 바랍니다.
기반 롤업에 대한 많은 논의와 흥분이 있었습니다. 그 이유는 매우 간단합니다. 기반 롤업은 기반이기 때문입니다. 구체적으로, 기반 롤업은 애플리케이션이 기본 계층에 고수할 수 있도록 허용합니다(+ 동기성 유지). 동시에 일반적으로 롤업과 앱 체인에 예약되어 있는 여러 가지 초능력을 얻습니다(보안을 유도하는 동안). 여기에는 사용자 지정, MEV 내부화 및 특수화와 같은 것이 있습니다. 과거에 기반 롤업에 대해 많이 언급하지 않은 이유는 과거의 구현 아이디어가 일반적으로 제안자를 과부하시키고 모든 것을 단일 체인으로 전환하는 데 중점을 두었기 때문입니다. 이는 이러한 극도로 분산된 시스템에서 확장할 수 없는 것입니다. 게다가 이러한 설정의 UX(사전 확인이나 소프트 보장이 없는 경우)는 애플리케이션이 원하는 수준에 미치지 못했습니다.
우리의 견해로는 기반 롤업에 대한 현재의 교리가 더 나은 방향으로 바뀌었습니다. 그러나 중요한 가정, 가정, 중앙 집중화에 대한 우려는 여전히 남아 있습니다. 아래에서는 기반 롤업이 과거에 어떻게 작동하도록 계획되었는지, 현재 구현이 어떻게 작동하는지, 그리고 궁극적으로 이상적인 프로토콜 외부 구현이 어떻게 보일지(그리고 프로토콜 내부 최종 게임)에 대한 간단한 개요를 제공합니다.
과거에는 기반 롤업 방식이 비용이 많이 들거나 기존 제안자에게 상당한 압력을 가하거나(그리고 끔찍한 UX를 제공하거나) 일반적인 Ethereum 참여자의 영역 밖에 있는 행위자와 중개자에게 의존하는 방식으로 구현될 가능성이 높다고 일반적으로 생각했습니다. 이는 L1 검증자가 기반 롤업 트랜잭션을 적극적으로 시퀀싱하고 실행하도록 하는 것(기본적으로 압축이 오프체인에서 발생하지만 단일 체인으로 전환)에 대한 많은 논의가 있었기 때문입니다. 다른 아이디어는 옵트인/옵트아웃을 중심으로 했지만 MEV-Boost 외부에 있었습니다. 알다시피 MEV-Boost는 대부분의 구축된 Ethereum 블록을 담당하기 때문에 프로토콜 외부의 활성 통합을 관리하고 추진력을 얻는 것이 훨씬 더 어렵습니다. 나중에 보시겠지만, "효율적인" 기반 롤업의 첫 번째 구현은 MEV-Boost 영향권 내에서 이루어질 가능성이 높다고 생각합니다. 통합과 적합성이 훨씬 쉬워지기 때문입니다.
아래 롤업에 대한 예시와 언급에서 압축은 체인 밖에서 발생한다는 점을 명심하세요(그리고 L1에 게시된 데이터는 압축된 형태로 이루어집니다). 우리는 이 작업을 처리하는 시퀀서가 있는 기존 L2에서 이에 꽤 익숙해 있습니다(그리고 전체 노드는 전체 상태를 유지합니다). 기반 롤업에서 압축 작업은 더 큰 문제입니다. 아래의 Taiko 예에서 누구나 이 압축을 수행할 수 있기 때문입니다. MEV-Boost 예에서 이는 기반 롤업에서 전체 노드를 실행하는 검색자와 빌더가 수행할 가능성이 높습니다. 여기서 주의해야 할 점은 다른 블록체인과 마찬가지로 전체 노드를 실행하려는 인센티브는 기반 롤업에서 상당한 추진력이 있어야 한다는 것입니다. 롤업에서 활동량이 충분히 많아 누군가가 압축 작업을 수행하거나 검색자와 빌더가 그곳에서 활동하게 되어야 합니다. 아니면 초기 부트스트래핑 단계에서 추가적으로 인센티브를 제공해야 합니다.
지금까지 Ethereum에서 기반 롤업의 라이브 구현 측면에서 가장 분명한 예는 Taiko로, 위에서 설명한 것과는 상당히 다르게 작동합니다. 또한 보다 통합된(엔드게임 이전) 솔루션이 어떻게 보일지와는 상당히 다른 방식으로 작동합니다. Taiko가 작동하는 방식에 대한 개요는 다음과 같습니다.
이더리움(및 기타 모놀리식 체인)의 현재 상태에서 매우 분명한 것은 이더리움 보안(및 동기성)을 도출하는 동안 사용자 정의, 특수화 및 MEV 유지를 갈망하는 많은 수의 애플리케이션이 있다는 것입니다. 우리는 이전에 모듈식 설정에 대한 이유를 여기 및 여기의 기사에서 꽤 자세히 다루었고, 앱 개발자가 모듈식으로 빌드하는 이유에 대한 두 가지 최근 프레젠테이션은 여기 및 여기 에서 다루었습니다.
MEV-Boost 사이드카 통합은 아마도 이와 비슷하게 보일 것입니다. 이를 위해서는 빌더가 지원되는 롤업과 통합해야 한다는 점을 명심하세요(MEV-Boost 릴레이와 같은 설정으로 바로 이동하지 않는 한, 위의 권한 중 많은 부분을 잃게 됩니다). 빌더는 점점 더 강력한 개체가 될 가능성이 높으며, 이는 나중에 설명하겠습니다. 제안자도 옵트인해야 하지만(현재 MEV-Boost에서 하는 것처럼), 이러한 기반 롤업 사이드카를 운영하는 제안자의 수익이 더 높으면 다른 사람들도 참여할 가능성이 높습니다(대부분 수익 추구).
이러한 구현이 Ethereum에서 어떻게 보일지에 대한 몇 가지 제안이 이미 있습니다(사전 확인 수준과 기반 롤업이 어떻게 들어맞을지에 대한 두 가지 모두):
기반 롤업의 경우:
사전 확인을 위해:
하지만 이것이 어떻게 완전히 구현될지에 대한 명확한 견해는 없습니다(모든 MEV-Boost 검증자와 빌더가 참여할 것처럼). 그러나 이러한 일들이 곧 일어날 것이라는 점과 먼저 핵심 프로토콜 밖에서 일어날 것이라는 점은 매우 분명합니다.
또한 코어 이더리움 커뮤니티 내에서 기반 롤업을 더 잘 지원하려는 명확한 욕구가 있습니다. 여기서 우리는 특히 단일 슬롯 확정성과 더 빠른 블록 시간을 원한다는 것을 언급하고 있습니다. 이는 기반 롤업에 훨씬 더 적합합니다. 이러한 것들은 이더리움의 대부분 업그레이드와 마찬가지로 상당히 멀리 떨어져 있습니다. 반면 사전 확인/제안자 커밋먼트는 메인넷과 테스트넷에서 이미 프로덕션에 있지만 커뮤니티 구성원의 상당한 반발을 받고 있습니다(다시 말하지만, 중앙 집중화 문제입니다. 계속해서 이에 대해 더 자세히 설명하겠습니다).
또한 일반적인 시간 범위인 1회 내에 여러 경매를 실행하여 단일 MEV-Boost 경매 내에서 부분 블록 구축을 활용하는 몇 가지 다른 흥미로운 아이디어(사전 확인을 제공하기 위한)도 있습니다. Linoscope (Nethermind)의 다중 라운드 MEV-Boost를 사용한 기반 사전 확인 에서 아이디어는 MEV-Boost 경매에서 고정된 수의 더 빠른 라운드가 있고, 여기서 부분 페이로드(블록)를 구축(및 서명)하고, 이 서명(제안자로부터)이 사전 확인 역할을 한다는 것입니다. 그런 다음 전체 블록(부분 페이로드 포함)이 일반 슬롯의 끝에서 정상적으로 전파됩니다. 위의 XGA 도 비슷한 아이디어를 사용합니다. 그러나 하나의 경매를 여러 개로 나누는 대신 블록 공간을 우선순위와 비우선순위의 두 레인으로 나눕니다. 이는 누출이 적은 미래 블록 공간을 판매할 수 있는 기능을 제공하기 위해 수행됩니다(너무 많은 MEV를 사용하지 않고). 즉, 검증자는 비우선순위 블록 공간에 대한 액세스(사전 확인을 위해)를 판매하게 됩니다.
슬래싱, 등록 및 가격 책정과 같은 사항은 단순화를 위해 제외되었음을 명심하세요.
위의 다이어그램에 설명된 사전 확인 프로토콜은 Spire 팀이 사전 확인 게이트웨이에서 제안한 것과 유사할 수 있습니다. 여기를 참조하세요 . 제안자/사전 협의자(시퀀서 역할을 위임했을 가능성이 높음)는 Ethereum 제안자 룩어헤드를 통해 미리 알려져 있습니다. 룩어헤드에 활성 사이드카 참여자가 없는 경우 기반 롤업은 폴백 메커니즘을 사용하여 시퀀서를 선출할 수 있습니다. 폴백 메커니즘( h/t mteam )에 대한 다른 사용 사례는 사전 협의 사이드카 참여자가 삭감되었거나 담보가 없는 경우일 수도 있습니다.
위의 많은 부분이 이더리움의 복잡성과 기반 롤업을 위한 플랫폼을 제공하기 위한 길에 초점을 맞추었지만, 이를 지원할 수 있는 다른 네트워크도 있습니다. 아래에서는 기반 롤업을 구축할 수 있는 몇몇 장소와 이를 지원하기 위해 특별히 구축된 네트워크를 다루겠습니다.
기반 롤업을 지원할 수 있는(그리고 지원하도록 구축된) 네트워크의 관점에서 보면 꽤 많은 것이 있습니다. 특히 주목할 만한 것은 공유 시퀀서인데, 이는 본질적으로 시퀀싱(기반) 롤업을 위한 네트워크입니다.
공유 시퀀서
아스트리아
에스프레소 커피
반지름
노드킷
데이터 가용성 계층(합의 포함)
셀레스티아
이익
빠른 모놀리스
Solana(대규모 생태계 + 효율적인 롤업을 가능하게 하는 속성)
요구 사항 및 속성
이더리움의 경우 , 요구 사항(적절한 UX와 위에 설명된 속성을 얻기 위한 요구 사항):
시퀀싱을 할 것인가, 말 것인가
약속해, 확인만 하면 돼
게다가, 우리가 보았듯이, 적어도 더 빠른 블록 이전에는 사전 확인이 필요합니다. 이것이 어떻게 구현될지에 대한 많은 논쟁이 있지만, 이미 고려해 볼 만한 가치가 있습니다. 다시 한번 강조하자면, 사전 확인은 제안자 또는 위임된 행위자가 제공하는 미래의 포함 또는 실행에 대한 약속으로, 지정된 시간에 상태를 잠그거나 액세스할 수 있는 능력이 있습니다. 기반 롤업에서 이는 제안자가 롤업 블록이 결국 실행/포함될 것이라는 보장을 제공할 수 있기 때문에 중요합니다. 이러한 계획에서 행위자에게 부과된 채권을 상당히 삭감하여 약속이 이행되도록 할 가능성이 분명히 있습니다. 이는 프로토콜 외부가 전체 프로토콜의 사회적 합의가 아닌 소수의 사람들에 의한 사회적 삭감으로 되돌아가기 때문에 이상적인 세계에서 프로토콜 내부입니다.
포함 보장
실행 위임, 블록 구축 및 시퀀싱
블록/tx가 블록에 포함될 것이라는 보장(실행 클라이언트에 의해 실행될 것이라는 보장은 아님) 또는 특정 순서로 배치될 것이라는 보장
애플리케이션 간 구성성을 보장할 수 없음
가격 책정이 더 쉽습니다
아웃소싱된 시퀀서(빌더)와 제안자의 협업(릴레이가 일반적인 역할을 수행할 가능성이 높지만 여기서도 부담이 있을 가능성이 높음)
실행 보장
실시간 유효성 증명 또는 담보화.
제안자에게 큰 부담을 준다
가격 책정이 더 어려움
기반 롤업이 Ethereum L1 상태를 동기적으로 터치할 수 있다는 점을 고려하면 중요합니다. 여기서 앱 구성성은 실행 보장을 요구합니다.
사전 확인은 현재 사용이 매우 제한적이지만, 더 넓은 범위는 매우 광범위하여 제안자 커미트먼트에 대해 다소 유연한 기본 계층을 제공할 수 있습니다. 제안자 커미트먼트의 현재 속성(사전 확인/커미트먼트 사이드카 제외)은 블록 생성 시 상태 확인(즉, 12초마다)으로 제한됩니다. 그러나 제안자가 특정 블록에 대해 다른 사람에게 커미트먼트를 발행하는 동시에 포함 사전 확인에서 키 기반 롤업 속성을 지원할 수 있는 몇 가지 프로토콜 외부 커미트먼트 계획(예: Chainbound)이 이미 있습니다. 위에서 설명한 대로, 이는 우리가 매우 원하는 것입니다. 프로토콜 외부 사전 확인에 관심이 있다면 Chainbound 팀의 이 강연을 적극 추천합니다.
더 나은 UX를 위한 더 빠른 블록을 넘어, 사전 확인이 테이블에 가져올 수 있는 다른 핵심 사항도 있습니다(기반 롤업에 사용되는 것 외에도). 다음과 같은 것들이 있습니다.
제안자 약속, 티켓 및 증명자
제안자 약속의 최종 목표는 매우 광범위하며, 다음과 같은 더 많은 사용 사례를 지원할 수 있다는 것이 일반적인 아이디어입니다.
프로토콜 내 커밋먼트 및 블록 제안 권한 측면에서 프로토콜 강제 제안자 커밋먼트(PEPC) 및 실행 티켓(ET) (+ 증명자-제안자-분리(APS) )과 같은 여러 제안 및 구현이 논의되고 있습니다. ET는 블록 제안 구매 권한에 대한 프로토콜 내 시장(복권)을 허용하기 때문에 상당한 주목을 받고 있습니다. APS에 대한 아이디어는 L1 검증자 역할을 실행 및 비콘(합의) 제안자의 두 가지 별도 역할로 분할한다는 것입니다. 전자는 블록 페이로드를 제안하는 작업을 맡게 됩니다(이것의 빌드는 빌더에게 아웃소싱되거나 빌더가 이 역할을 수행하게 됩니다). 후자(비콘 또는 증명자)는 설정된 블록 유효성 규칙에 대한 투표 작업을 맡게 되고(더 많은 규칙이 설명될 가능성이 높으므로 기반 롤업 블록에서 특히 중요함) 포함 목록을 통해 실행 권한을 제한합니다. 이는 (특히 사전 확인 및 기반 롤업을 중심으로 한 슈퍼 빌더와 중앙 집중화 우려의 세계에서) 더 높은 검열 저항을 제공할 가능성이 높습니다. 사전 확인 역사에 관심이 있다면 ( 여기를 확인하세요 ).
그들은 커지고 있어요
슈퍼빌더
이 기사에서 알아차렸을 수 있듯이, 과부하를 피하거나 더 나은 시장 효율성을 보장하기 위해 더 전문화된 행위자에게 많은 위임과 아웃소싱이 있습니다. 이것이 의미하는 바는, 그리고 그것이 이끄는 바는 이더리움에서 한동안 일어나고 있다는 것입니다. 즉, 대부분의 막대한 작업을 빌더(매우 정교한 엔티티)의 손에 맡기는 명확한 길입니다. 이것은 "슈퍼 빌더"로 불리는 것으로 이어지고 있습니다. MEV-Boost 파이프라인 내의 현재 빌더 그룹은 기반 롤업, 사전 확인 및 커밋에 대한 프로토콜(및 외부)에서 핵심 역할을 할 가능성이 높습니다.
그 이유는 매우 명확합니다. 우리는 이더리움의 합의를 과부하시키고 싶지 않습니다. 우리는 모든 제안자에게 전문화되도록 요구할 수 없고, 그렇게 할 수도 없습니다. 일반적인 시장 힘이지만, 중앙 집중화로 이어지고, 그와 함께 많은 위험이 따릅니다. 이는 오늘날 이미 적용되고 있으며, 3개의 빌더가 오늘날 대부분의 이더리움 블록을 구축하고 있습니다(Titan과 Beaverbuild라는 두 회사가 거의 80%를 구축하고 있습니다!). 오늘날 제안자들은 또한 릴레이와 매우 신뢰할 수 있는 관계를 맺고 있습니다(이는 ePBS의 발전으로 완화될 것으로 기대되지만, 아직은 명확하지 않습니다)
빌더는 (기반 롤업 사례에서) 시퀀싱, 실행 보장 및 블록 구축 이유로 롤업에서 전체 노드를 실행할 가능성이 높습니다. 동시에 (사전 협의 사례에서) 이러한 블록/번들의 가격을 올바르게 책정할 수 있어야 합니다(일부 빌더는 이 사전 협의 가격을 검색자에게 아웃소싱할 수 있음). 포함 보장 사전 확인은 가격을 책정하기가 훨씬 쉬운 반면, 실행 보장은 상당한 정교함이 필요하고 여전히 미해결 문제입니다.
기반 롤업에 대한 주제에서, 슈퍼 빌더는 일반적으로 단일 체인(이더리움)이 아니라 여러 체인(이더리움+롤업)을 위해 빌드하는 전문화된 행위자로 간주될 수 있습니다. 이는 특히 블록 내 동기성과 크로스 도메인 롤업 상호 운용성을 원하는 경우에 필요합니다. 어느 정도 Optimism의 슈퍼체인 시퀀서/빌더를 OP-Stack 체인의 슈퍼 빌더로 볼 수도 있습니다. Astria/Espresso의 분산 시퀀서 네트워크(단일 리더가 없는 경우 다중 동시성)도 마찬가지입니다. 빌더에게 위임하는 것의 흥미로운 측면은 여러 롤업의 티켓 보유자가 이러한 도메인에서 동기적 구성성에 대한 포함 보장을 제공할 수 있다는 것입니다.
슈퍼빌더라는 용어는 본래의 의무(빌딩 블록!) 외에 수행하는 과외 활동을 지칭하는 데에도 사용될 수 있습니다. 여기에는 약속이나 사전 확인이 포함됩니다.
이 모든 경우에 빌더에게 상당한 채권(지분)이 필요할 가능성이 높은데, 특히 그들에게 위임된 작업이 늘어나고 있기 때문입니다. 가급적이면 그들에게 아웃소싱된 이러한 기능의 대부분은 공정하고 견고하며 올바른 슬래싱을 보장하기 위해 온체인(프로토콜 내)에서 증명 가능해야 합니다. 이는 빌더 측에서 수평적 확장이 증가한다는 신호입니다(저스틴 드레이크가 무심코 괜찮다고 말했나요?). 여기에는 멀티 블록 MEV, 다른 모든 빌더보다 훨씬 더 많은 롤업을 위해 빌더를 빌드하는 것(또는 MEV 추출에 더 능숙한 것) 및 다른 모든 빌더보다 지속적으로 입찰에서 이길 수 있는 가능성과 같은 꽤 많은 우려가 있습니다. 이러한 추가적인 정교함과 최적화는 모든 것과 마찬가지로 더욱 중앙 집중화되고 새로운 참여자에게 진입 장벽이 높아질 것입니다(Citadel이 아닌 한). 매우 분명해 보이는 한 가지는 빌더가 훨씬 더 많은 권한을 부여받은 세상에서 적어도 포함 목록(IL)이 절실히 필요하다는 것입니다.
이는 흐름이 점점 오프체인/개인 주문 흐름으로 이동하고 있다는 사실에 더해집니다. 독점적 공급자(및 통합된 공급자)가 있는 빌더는 없는 빌더보다 훨씬 더 나은 성과를 거두며, 이러한 소수는 모든 기반 롤업 통합에서 가장 많은 이익을 얻을 가능성이 높습니다. 일부 애플리케이션(또는 Telegram 봇)에 롤업이 있고 빌더에 대한 독점적 흐름이 있는 경우에도 이는 걱정스러울 수 있습니다. Burak Öz , Danning Sui , Thomas Thiery , Florian Matthes 는 최근 논문 Who Wins Ethereum Block Building Auctions and Why? 에서 이러한 문제를 잘 강조했으며, 특히 위에 제시된 진입 장벽이 높은 문제에 대해 강조했습니다.
빌더에 대한 작업 증가에 대한 흥미로운 단서는 수익 분배 측면에서 그들이 (적어도 온체인에서) 가장 적게 받는다는 것입니다. 세 가지 주요 빌더 중 두 개가 소품 매장이기도 하지만 검색자 수익도 분명히 그들의 진영에 많이 있습니다. 거래하지 않는 빌더조차도 플로우에서 거래하지 않기 때문에 검색자와 수익 분배에 대한 계약을 맺을 가능성이 높습니다. 현재 Yuki (Sorella/Fenbushi)가 지적했듯이 MEV에서 비MEV 수익은 거의 동등하게 나뉘며, 많은 양의 수익이 신청을 위해 테이블에 보관되어 종종 제안자의 손에 들어갑니다.
매우 명확하게 드러나는 한 가지는 자체/타인의 MEV를 포착(내재화)할 수 있는 애플리케이션(또는 프로젝트)에 엄청난 기회가 있다는 것입니다. 분명히 오늘날 체인에서 경제 활동이 활발하기 때문에, 그렇지 못한 애플리케이션보다 경쟁에서 이길 수 있을 것입니다. 테이블에 남겨진 이러한 마진은 애플리케이션이 더 좋고 더 효율적이 될 수 있는 프로토콜에 대한 기회입니다.
애플리케이션은 롤업 기반 앱을 어떻게 빌드할까요?
훨씬 앞서 언급했듯이, 기반 롤업으로 애플리케이션을 빌드하는 데는 여러 가지 이유가 있습니다. 특히 이미 기반 계층에 자리 잡고 배포된 경우 더욱 그렇습니다. 기존 계약을 L1에 유지하면서 기반 롤업으로 애플리케이션을 출시하는 방법에 대한 예를 들어보겠습니다.
Uniswap의 경우, Uniswap 라우터를 기반 롤업에 라이브로 두고, 애플리케이션이 롤업을 통해 호출을 하도록 할 수 있습니다(즉, Uniswap은 경매를 통해 실행되는 흐름의 일부를 내부화할 수 있습니다). 예를 들어, L1 Uniswap 유동성을 터치하려는 인텐트 프로토콜은 기반 롤업의 라우터를 통해 호출을 해야 합니다.
미래 연구 및 마무리 생각
그러나 분명한 것은 구성 가능한 동시에 사용자 정의, 내재화 및 보안 도출 기능을 원하는 매우 잘 개발된 일체형 체인 기반의 대규모 애플리케이션 생태계가 있다는 것입니다.
특정 애플리케이션을 위한 주문 독립적인 시퀀싱(예: 주문 문서 참조) - MEV 내부화뿐만 아니라 검증 가능한 시퀀싱 규칙, 빈번한 일괄 경매, 공정한 주문 등
특정 포크 선택 규칙 롤업(예: Oracle 가격이 업데이트된 경우에만 유효한 블록)
최적의 블록 유효성(최고 수수료 이상)은 매우 임의적일 수 있습니다(예를 들어 => 가치 극대화와는 다름)
블록 빌더의 정교함과 수평적 확장에는 위험성(+ 다중 블록 mev, 블록 입찰)에 대한 추가 연구가 필요합니다. 이것이 명령어/가스 제한/VM/포크 선택 규칙 특수화에 따라 어떻게 바뀌는지요.
부분 블록 구축 + 다중 동시 제안자
프로토콜 내부 및 프로토콜 외부 포함 목록을 사용하여 블록 빌더 제한
통합되지 않은 빌더에 대한 가격은 검색자에게 위임된 경우?
주문 흐름에 대한 롤업 결제
연속 블록 구축( 솔라나의 Shreds와 유사 )
타이밍 게임 및 효과 (+ 잘못된 헤드 투표 증명 )
현재 단일 체인에서 동작하는 애플리케이션이고, 구성 가능한 상태를 유지하면서 기본 계층과 일치하는 모듈성의 측면을 어떻게 활용할 수 있는지 알아보는 데 관심이 있다면(지난 1년 동안 여러 번 다루었듯이) 언제든지 저희에게 문의하세요.
추가 읽기:
https://research.chainbound.io/examineing-the-based-sequencing-spectrum
https://mteam.space/eth-sequencing-preconfs-resources/based_rollups.html
https://ethresear.ch/t/based-rollups-superpowers-from-l1-sequencing/15016
https://blog.20squares.xyz/preconfirmations-splitting-the-block/
https://mirror.xyz/preconf.eth/3SXageNPpcQMz8L2YfW5ipvthNl-InPzaPAfb3LxwqA
검토를 위해 Mathijs van Esch(Maven11) 및 mteam(Spire)에게 감사드립니다.
