WebAuthn Signature Flow Sequence Diagram sequenceDiagram participant Client participant Server participant Blockchain Client->>Server: beginRegistration(username) Server->>Client: challenge Client->>Client: embed challenge into session token { challenge: challenge, ... }

Designing a Sequencer Deployment Service Objective: Cartridge operates Slot, a managed infrastructure as a service solution which developers to rapidly deploy sequencers and indexers at the edge, providing high performance, low latency execution contexts for players. For this task, we would like you to propose an architecture that accomplishes that same goal. Please review the requirements below and put together a document / architecture diagram with your proposed solution. As a follow up, we will schedule a call to walk through the solution together. It is not necessary for the design document to cover all the requirements below but pleaes be ready to discuss them during our follow up call. The primary focus of this exercise is on the reasoning behind your design choices, rather than specific technologies. Requirements: Architecture Overview:Describe the key components you would include in the deployment service architecture. Thinking through the entire lifecycle of a users request, both on the developer side spinning up a sequencer and on the player side interacting with a sequencer.

Predeploy Controller account contracts to Katana (similar to UDC) Inside Slot, we know the master account and can fund a users controller for deployment When a user tries to interact with a new chain, Slot sends ETH to fund the controller address a. [If deploy on invoke is supported] Controller prompts user to sign a session token, the session token is used to invoke the registerSession method, with the included account deployment calldata. b. a. [If deploy on invoke is not supported] Controller prompts user to sign a session token, the session token is used to deploy the account. Ideally, we can register the session token in the deploy txn.

Summary The proposal focuses on deploying Dope World (DW) and Roll Your Own (RYO) as a Layer 3 (L3) application on top of the OP Mainnet. This proposal is an extension of DIP-75: Dope World, the first version of RYO will still be deployed to Starknet in the short term according to the original proposal. This extension will utilize Cartridge Slot with Katana for execution, taking advantage of zero-knowledge proofs (zkproofs) and fractal scaling to provide cheap, low latency, high throughput compute that will be settled on to OP Mainnet. The L3 network will use PAPER tokens for transaction fees. The proposal also includes the development of a bridge between Layer 2 (L2) and L3 for briding tokens and data between the networks. Technical Specification Layer 3 Deployment: DW and RYO will be launched as an L3 application, leveraging the scalability and efficiency of Dojo and Cartridge Slot. The exact scaling architecture is still being defined, there will likely be a persistent Dope World Layer 3 and potentially ephermeral Layer 4 (L4) sequencers used for RYO sessions. Use of Zero-Knowledge Proofs: DW and RYO game rounds will employ zkproofs for aggregating and settling transactions onto the OP Mainnet. This reduces transaction costs, while maintaining the integrity and transparency of the game. Leveraging this technology entails deploying a STARK verifier and fact registry to OP Mainnet, necessary for registering outcomes of higher layers to lower layers.

This document describes the implementation of Saya, an addition to the Dojo toolchain, which serves to settle Katana sequencers to a settlement layer. The document consists of several phases, progressively extending the support for additional settlement chains and data availability providers. 2023-11-28 12.09.32 Stage Generating the trace and state diff This initial task entails the scaffolding of the Saya service. A rust service that runs along side a Katana instance. Saya is responsible for pulling blocks from Katana, executing them and generating the corresponding execution trace and state diff. This should probably extend the existing SNOS implementation. In order to generate the execution trace and state diff, the Starknet OS needs to be executed. There is an existing effort to support this for Madara. It expects the following input:

WebAuthn is an industry standard specification for accessing Public Key credentials. It defines a set of APIs and interfaces for securely generating keypairs that can subsequently be used for user authentication. The specification is widely supported (Apple, Google, Microsoft) and provides an array of configuration options, each with different usability and security tradeoffs. In the most usable configuration, platform authentications (Face ID, finger print, ect) provide a simple way for users to securely generate + manage their keypair. Many platforms today include secure elements which can be leveraged through the webauthn api. Passkeys further improve user experience by transparently synchronizing credentials across devices and supporting recovery through the root platform account (i.e. iCloud). In the most secure configuration, roaming authentications allow specialized hardware to generate credentials and assertions, allowing users to manage their credentials using FIDO2 compliant devices such as Yubikeys or a Ledger (coming soon). This massive shift in authentication logic is being catalyzed by existing software and hardware providers that represent almost the entirety of the device ecosystem today. Supporting Webauthn credentials allows Starknet to capitalize this momentum, to provide a massive improvement in blockchain usability and, to provide a path for mainstream user adoption. To summarize:

WebAuthn is an industry standard specification for accessing Public Key credentials. It defines a set of APIs and interfaces for securely generating keypairs that can subsequently be used for user authentication. The specification is widely supported (Apple, Google, Microsoft) and provides an array of configuration options, each with different usability and security tradeoffs. In the most usable configuration, platform authentications (Face ID, finger print, ect) provide a simple way for users to securely generate + manage their keypair. Many platforms today include secure elements which can be leveraged through the webauthn api. Passkeys further improve user experience by transparently synchronizing credentials across devices and supporting recovery through the root platform account (i.e. iCloud). In the most secure configuration, roaming authentications allow specialized hardware to generate credentials and assertions, allowing users to manage their credentials using FIDO2 compliant devices such as Yubikeys or a Ledger (coming soon). This massive shift in authentication logic is being catalyzed by existing software and hardware providers that represent almost the entirety of the device ecosystem today. Supporting Webauthn credentials allows Starknet to capitalize this momentum, to provide a massive improvement in blockchain usability and, to provide a path for mainstream user adoption. To summarize: