You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For quite some time now we've been working on smart contract based exits. This moves the exit database from a shared postgresql database into a solidity contract in an EVM execution environment.
At this stage a lot of the work has already been done, we have the contract, which lists both clients and exits. Clients use the list of exits on the smart contract to determine what exits it is safe to connect to. Likewise Exits use the client list to decide what clients to allow access.
Next Steps
Exit root of trust server consider the case where we have a new exit and several clients downstream. The exit is new and has all of it's keys auto-generated, but it's registered in the smart contract. The clients will happily connect to it, but only once they know it's on the exits list, since this exit didn't exist when the firmware image for those routers was created there's no way to get the information that the exit is safe to use to those routers, without them using that exit to setup in the first place. In order to break this deadlock we provide the root of trust server, what this server does is respond to requests with a signed copy of the exit list from the smart contract. All exits then request this signed copy, and pass it onto clients. The client routers will get this signed copy from the exit, verify the signature versus a signing key in their config, then connect to the exit where they will be able to go and query the smart contract themselves from then on.
The root of trust server should be deployed via github actions to a digital ocean droplet, using the usual ansible automation
A number of eth keys will be generated and put into the router configs, the root of trust server will be configured with one of these via github secret @jkilpatr will set this up and collect keys from other community participants
The root of trust server will have access to a sms auth key, which it will use to provide an api for registering clients to the smart contract if they pass sms auth. Rita exit will then call this api when it gets a registration request from a client.
A dashboard for the exit registration smart contract should be created, allowing viewing of the registered exits and clients. The root of trust backend should be expanded to allow registration and removal of clients using the frontend. Think https://github.com/Gravity-Bridge/gravity-info-api but with a few cases where it sends tx's @ChristianBorst should advise on this one
Rita and Rita exit updates
Rita exit will query the signed exit list and keep a copy in memory (using actix web data rather than lazy static). Rita exit will setup a webserver on a hardcoded ip address, this will allow clients to find the exit to query the list without knowing the ip of the new exit, which will be random and of course can't be known in advance.
Rita client will then query that webserver for the exit list, and after being setup update it's exit list regularly by using the same query command that the root of trust server would since it now has access to the internet
Rita client dashboard will need updates to handle the new structure of exits specifically registration and debugging.
Rita exit needs to update the registration endpoints to call the exit root of trust registration api
For quite some time now we've been working on smart contract based exits. This moves the exit database from a shared postgresql database into a solidity contract in an EVM execution environment.
At this stage a lot of the work has already been done, we have the contract, which lists both clients and exits. Clients use the list of exits on the smart contract to determine what exits it is safe to connect to. Likewise Exits use the client list to decide what clients to allow access.
Next Steps
Exit root of trust server consider the case where we have a new exit and several clients downstream. The exit is new and has all of it's keys auto-generated, but it's registered in the smart contract. The clients will happily connect to it, but only once they know it's on the exits list, since this exit didn't exist when the firmware image for those routers was created there's no way to get the information that the exit is safe to use to those routers, without them using that exit to setup in the first place. In order to break this deadlock we provide the root of trust server, what this server does is respond to requests with a signed copy of the exit list from the smart contract. All exits then request this signed copy, and pass it onto clients. The client routers will get this signed copy from the exit, verify the signature versus a signing key in their config, then connect to the exit where they will be able to go and query the smart contract themselves from then on.
Rita and Rita exit updates
The text was updated successfully, but these errors were encountered: