-
Notifications
You must be signed in to change notification settings - Fork 39
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Create session_keys_on_ten_gateway.md
- Loading branch information
1 parent
2081f6f
commit 3abdccc
Showing
1 changed file
with
57 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -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 |