From 3abdccc92caa8fabf1fe94d3662dd2ff8febe6d4 Mon Sep 17 00:00:00 2001 From: Tudor Malene Date: Wed, 14 Aug 2024 13:19:59 +0100 Subject: [PATCH 1/4] Create session_keys_on_ten_gateway.md --- design/ux/session_keys_on_ten_gateway.md | 57 ++++++++++++++++++++++++ 1 file changed, 57 insertions(+) create mode 100644 design/ux/session_keys_on_ten_gateway.md diff --git a/design/ux/session_keys_on_ten_gateway.md b/design/ux/session_keys_on_ten_gateway.md new file mode 100644 index 0000000000..0ec02eb55a --- /dev/null +++ b/design/ux/session_keys_on_ten_gateway.md @@ -0,0 +1,57 @@ +# Session keys on Ten + +EIP-4337 (Account Abstraction) has popularised the concept of "Session keys" to minimize clicks. + +We want to offer a similar user-friendly experience to Ten dApp devs. + +To test the concept we will convert the Battleships game to a no-click UX. + + +## The Ten Gateway as a Session Key manager + +The TG already manages VKs on behalf of users, so adding SKs is relatively straight forward. +The advangate of the TG managing SKs is that it can return the funds to the EOA at any time. +Anothe advantage is that they can be reused between sessions to avoid unecessary transactions. + + +### The flow + +The logic of the game UI (javascript), will call and endpoint that will return a value transfer transaction that the user must sign in their MM, together with the address of the SK. + +The value transfer is required to prepay for the moves. + +*Note: If the user authenticates with a service that is happy to prepay (a paymaster) then the signing step is not required.* + +The game will create unsigned move transactions, and will submit them to the gateway. +The TG will sign these transactions with the SK and submit them to the network. + + +## Data ownership + +The SKs are a proxy for the EOA, so we want the EOA to read all data belonging to the SKs. +The SKs are tx signers so the platform will treat them as EOAs. + +We need to introduce platform level support for SKs. + +### The main place will the `externally_owned_account` table: + +``` +create table if not exists obsdb.externally_owned_account +( + id INTEGER AUTO_INCREMENT, + address binary(20) NOT NULL, + owner INTEGER, // this is a new field that will be populated for SKs and will point to the main account + primary key (id), + INDEX USING HASH (address) +); +``` + +Todo : + - Query for events: + - Query for receipts: + - T + +### RPC endpoint on Node - Register session key + +- Receives a session key signed by a VK signed by the EOA. +- Stores it to the `externally_owned_account` table and points to the true EOA From def745cf5da9638f8d49f0535642f185385c3ddd Mon Sep 17 00:00:00 2001 From: Tudor Malene Date: Wed, 14 Aug 2024 15:33:14 +0100 Subject: [PATCH 2/4] Update session_keys_on_ten_gateway.md --- design/ux/session_keys_on_ten_gateway.md | 26 ++++++++++++++++-------- 1 file changed, 18 insertions(+), 8 deletions(-) diff --git a/design/ux/session_keys_on_ten_gateway.md b/design/ux/session_keys_on_ten_gateway.md index 0ec02eb55a..a3157285ef 100644 --- a/design/ux/session_keys_on_ten_gateway.md +++ b/design/ux/session_keys_on_ten_gateway.md @@ -1,28 +1,38 @@ # Session keys on Ten -EIP-4337 (Account Abstraction) has popularised the concept of "Session keys" to minimize clicks. +EIP-4337 (Account Abstraction) has popularised the "Session keys" concept to minimize clicks. We want to offer a similar user-friendly experience to Ten dApp devs. -To test the concept we will convert the Battleships game to a no-click UX. +To test the concept, we will convert the Battleships game to a no-click UX. ## The Ten Gateway as a Session Key manager -The TG already manages VKs on behalf of users, so adding SKs is relatively straight forward. -The advangate of the TG managing SKs is that it can return the funds to the EOA at any time. -Anothe advantage is that they can be reused between sessions to avoid unecessary transactions. +*Reminder: A session key (SK) is a key that is not managed in a wallet and can be used to sign behind-the-scenes operations without user action.* + +Without smart contract wallets, a SK must have a balance to pay for gas. + +The browser can manage SKs on behalf of the user, but it can lose the gas if the browser crashes. + + +The TG already manages VKs on behalf of users, so adding SKs is relatively straightforward. + +The advantage of the TG managing SKs is that it can return the funds to the EOA anytime. + + +Another advantage is that they can be reused between sessions to avoid unnecessary transactions. ### The flow -The logic of the game UI (javascript), will call and endpoint that will return a value transfer transaction that the user must sign in their MM, together with the address of the SK. +The logic of the game UI (javascript) will call an endpoint on the TG that will return a value transfer transaction that the user must sign in their wallet, together with the address of the SK. The value transfer is required to prepay for the moves. -*Note: If the user authenticates with a service that is happy to prepay (a paymaster) then the signing step is not required.* +*Note: If the user authenticates with a service that is happy to prepay (a paymaster), then the signing step is not required.* -The game will create unsigned move transactions, and will submit them to the gateway. +The game will create unsigned move transactions and submit them to the gateway. The TG will sign these transactions with the SK and submit them to the network. From f5b62f0ff40c1d3519fe1478e89409aece938271 Mon Sep 17 00:00:00 2001 From: Tudor Malene Date: Thu, 15 Aug 2024 13:40:03 +0100 Subject: [PATCH 3/4] Update session_keys_on_ten_gateway.md --- design/ux/session_keys_on_ten_gateway.md | 53 +++++++++++------------- 1 file changed, 25 insertions(+), 28 deletions(-) diff --git a/design/ux/session_keys_on_ten_gateway.md b/design/ux/session_keys_on_ten_gateway.md index a3157285ef..0e40f939b4 100644 --- a/design/ux/session_keys_on_ten_gateway.md +++ b/design/ux/session_keys_on_ten_gateway.md @@ -20,48 +20,45 @@ The TG already manages VKs on behalf of users, so adding SKs is relatively strai The advantage of the TG managing SKs is that it can return the funds to the EOA anytime. - Another advantage is that they can be reused between sessions to avoid unnecessary transactions. ### The flow -The logic of the game UI (javascript) will call an endpoint on the TG that will return a value transfer transaction that the user must sign in their wallet, together with the address of the SK. +#### Create +The logic of the game UI (javascript) will call an `/session_key/create` endpoint on the TG, which will return the account address corresponding to the SK. +The game UI will create a value transfer transaction from the main account to this address with enough money to prepay for the moves. The user must sign it with their wallet. + +The game will call `/session_key/activate/${sk_account}` + +After the initialisation, the game will create unsigned move transactions and submit them to the TG. +The TG will sign these transactions with the active SK and submit them to the network. + +#### Reuse + +If the user already has a session key, the game can retrieve it with `/session_key/list`. This will return a list of `address, amount`. +The game has the option to top up the value, or activate it. -The value transfer is required to prepay for the moves. +#### Ending the game -*Note: If the user authenticates with a service that is happy to prepay (a paymaster), then the signing step is not required.* +The game can create transactions to move the values accumulated by the Sk to the main account, and submit them to the TG. -The game will create unsigned move transactions and submit them to the gateway. -The TG will sign these transactions with the SK and submit them to the network. +When that is finished: `/session_key/deactivate`, which returns `address, amount`. +#### Deleting a SK -## Data ownership +SKs need to be stored on the TG to allow the user to query in the future -The SKs are a proxy for the EOA, so we want the EOA to read all data belonging to the SKs. -The SKs are tx signers so the platform will treat them as EOAs. +#### Exporting the SKs -We need to introduce platform level support for SKs. +`/session_key/export/${sk_account}` - returns the private key -### The main place will the `externally_owned_account` table: -``` -create table if not exists obsdb.externally_owned_account -( - id INTEGER AUTO_INCREMENT, - address binary(20) NOT NULL, - owner INTEGER, // this is a new field that will be populated for SKs and will point to the main account - primary key (id), - INDEX USING HASH (address) -); -``` +### Implementation on the Ten Gateway -Todo : - - Query for events: - - Query for receipts: - - T +1. Store SKs in the database and manage them via the `session_key` endpoints +2. Sign the SK account with the vk of the user +3. Mark a session active per user and sign transactions with the SK +4. When the user queries data, also include the SKs as candidates. Todo: think about when the data needs concatenation -### RPC endpoint on Node - Register session key -- Receives a session key signed by a VK signed by the EOA. -- Stores it to the `externally_owned_account` table and points to the true EOA From e54d8cfca86972c38962653d5da8964cf954f24a Mon Sep 17 00:00:00 2001 From: Tudor Malene Date: Mon, 19 Aug 2024 09:41:59 +0100 Subject: [PATCH 4/4] Update session_keys_on_ten_gateway.md --- design/ux/session_keys_on_ten_gateway.md | 41 +++++++++++++++--------- 1 file changed, 25 insertions(+), 16 deletions(-) diff --git a/design/ux/session_keys_on_ten_gateway.md b/design/ux/session_keys_on_ten_gateway.md index 0e40f939b4..40630cc67a 100644 --- a/design/ux/session_keys_on_ten_gateway.md +++ b/design/ux/session_keys_on_ten_gateway.md @@ -11,12 +11,10 @@ To test the concept, we will convert the Battleships game to a no-click UX. *Reminder: A session key (SK) is a key that is not managed in a wallet and can be used to sign behind-the-scenes operations without user action.* -Without smart contract wallets, a SK must have a balance to pay for gas. +Without smart contract wallets, a SK must have a balance to pay for gas. The browser can manage SKs on behalf of the user, but it can lose the gas if the browser crashes. -The browser can manage SKs on behalf of the user, but it can lose the gas if the browser crashes. - -The TG already manages VKs on behalf of users, so adding SKs is relatively straightforward. +The Ten Gateway (TG) already manages VKs on behalf of users, so adding SKs is relatively straightforward. The advantage of the TG managing SKs is that it can return the funds to the EOA anytime. @@ -29,36 +27,47 @@ Another advantage is that they can be reused between sessions to avoid unnecessa The logic of the game UI (javascript) will call an `/session_key/create` endpoint on the TG, which will return the account address corresponding to the SK. The game UI will create a value transfer transaction from the main account to this address with enough money to prepay for the moves. The user must sign it with their wallet. -The game will call `/session_key/activate/${sk_account}` +The game will call `/session_key/activate/${sk_account}`. From then on, all transactions originating from that userID will be considered as part of the session. -After the initialisation, the game will create unsigned move transactions and submit them to the TG. +After the activation, the game will create unsigned move transactions and submit them to the TG. The TG will sign these transactions with the active SK and submit them to the network. -#### Reuse +#### Reuse SK with a balance -If the user already has a session key, the game can retrieve it with `/session_key/list`. This will return a list of `address, amount`. -The game has the option to top up the value, or activate it. +If the user already has a session key, the game can retrieve it with `/session_key/list`. This will return a list of `$address, $amount`. +The game has the option to top up the value of an account. If there is enough balance, activate it. #### Ending the game -The game can create transactions to move the values accumulated by the Sk to the main account, and submit them to the TG. +When the game ends, it will create "cleanup" transactions that move the values accumulated by the Sk to the main account, and submit them to the TG. + +*Note that the TG will sign these with the SK.* -When that is finished: `/session_key/deactivate`, which returns `address, amount`. +To finish the session, the game will call: `/session_key/deactivate` which returns `address, amount`. #### Deleting a SK -SKs need to be stored on the TG to allow the user to query in the future +SKs need to be stored on the TG to allow the user to query the data of previous games in the future. +If that data is not relevant, it is recommended for performance reasons to delete the SK with: ``/session_key/delete/${sk_account}``, after making sure it has no balance. #### Exporting the SKs `/session_key/export/${sk_account}` - returns the private key +This can be used for advanced use cases, or as a backup after deletion. + ### Implementation on the Ten Gateway -1. Store SKs in the database and manage them via the `session_key` endpoints -2. Sign the SK account with the vk of the user -3. Mark a session active per user and sign transactions with the SK -4. When the user queries data, also include the SKs as candidates. Todo: think about when the data needs concatenation +1. Store SKs in the database and manage them via the `session_key` endpoints: create/delete, activate/deactivate, list +2. On create: generate a k-v pair and sign the SK account (from the new k-p) with the vk of the user. Note: maybe create a new type of "signature" for sks. +3. When the `activate` endpoint is called, we need to set a flag for that user. And add extra logic in the `sendTransaction(Raw)` endpoint to sign transactions with the SK. +4. We should limit the number of SKs per user to 1 or 2. +5. When the user queries data, also include the SKs as candidates. Todo: think about when the data needs concatenation + +### Security consideration +The UserId or the RPC URL should not be exposed to the browser. +Find out why we need it currently. +If we need it for tenscan functionality, we need to find alternatives.