The Rollups Node uses a library called Transaction Manager to send Ethereum transactions. Being a library means that every Node needs its own Ethereum account to sign the transaction. If two Nodes share the same Ethereum account, there is a race condition where some of the transactions can fail.
The Problem
A DApp validator wants to manage several DApps at the same time. To do that with the existing Node, they would need to create a new Ethereum account for each DApp. Then, manage the funds of each account. This also means they would need multiple Authority contracts, one for each DApp.
Proposed Solution
Create a transaction manager service responsible for signing and sending the transactions. By concentrating this task on a single service, we can guarantee there won’t be any race conditions. Then, we modify the node to use this service to send transactions.
This problem will arise in the Dave Node, so it could eventually leverage the same solution.
Existing Solutions
Some SAAS solutions solve the problem we need to solve. For instance:
There are several possible architectures, but none of them are trivial to implement or deploy in a safe way.
I think my favorite one is still making the component who is in control of the business logic to be extended to support multiple dapps with a single wallet. And that is the claimer, not the tx-manager.
Even if that means not having a reusable service. The reusable library is still there (for rust at least).
It seems to me that sharing a transaction manager across different nodes is a huge convenience gain, especially for professional validators that hope to secure many different dapps.
It also seems like a problem that many other projects share. Which means that there are probably some good solutions to explore out there. If no one managed to solve this well, either we’re thinking about the problem wrong or it’s a very hard problem. But its also an opportunity to build something that can be used by other projects.
Is it the case of just transforming the tx-manager into a service or would it need a more complete overhaul? If it’s the latter, I’d first study the existing solutions and only then make the call.
Yes, that is an option as well. Currently the claimer is a internal node component, which is one-per-dapp. We would need to externalize this component into an individual self-sufficient service. For instance, we would need an API and its own layer of persistence.
I like that one too, but does it solve the problem if we have a DAVE node?
Even if DAVE is also multi-dapp, we’d at least two different nodes per validator potentially sending transactions together. If one day we create automatic execution of vouchers and add a node/service for that, it would also have to deal with synchronizing transactions etc.
So I don’t think its either one or the other…maybe both are worth doing. What do you think?
Yes, we can do both. If we create a service for the transaction manager, we can use it in the current, multi-dapp, and Dave nodes.
This decision also depends on the scope of the Dave node. If it is a program we run manually on our local machines only when a dispute happens, then it might be simpler to use the existing state-fold library as is. If it is a service that will run in the cloud and should automatically run disputes for multiple DApps, it will significantly benefit from a transaction manager service.
Dave is a different scenario that I don’t think should be under consideration for this particular problem.
Starting with the fact that Dave is permissionless, so it should not be affected by the limitations of Authority which is the root issue of the discussion.
If I’m running different DApps at the same time, regardless of the type of node (DAVE, or Authority), I’d run into nonce synchronization issues and lack of general convenience for transaction managing.
I think the only scenario in which this solution wouldn’t be that useful is if there a single node for all the dapps and functions - meaning that anything that sends a transaction to the blockchain is together. I don’t think this is the way we should go, I believe in different kind of nodes (prover, reader, claimer, vouchers etc)
Do you already know if the Dave claimer will need to be permissioned? Isn’t it the whole point that it’s not? So any account could be claiming/challenging? If it’s any account the Dave node could use his own account.
Yeah, the whole point of DAVE is that it’s gonna be permissionless. Any account could be used, even many different ones. I think you could even have one address for each interactions with the game.
What I’m saying, though, is that having a bunch of accounts interacting with the blockchain at the same time is a pain in the ass. And this would help solve it.
But I agree that in the case of an Authority, one would suffer even more: because the interactions have to be coming from the same address and there is no way to escape (other than having different Authority addresses, which is unsafe and annoying).
Just for the record, another possibility is to have a more elaborate Authority with AccessControl (instead of Ownable), and adding several accounts with Claimer Role. This can be used for “one account per dapp”, or any other sharding technique in between.
Question 2 - Your first question answer my second, it simple stop making sense lol. About the third question: My point is on implementing this feature what is your goal? Just saving headache? Is this headache relevant enough to have a solution? In the scenario of several accounts, in case of a Node running several dApps, those accounts have to be created manually?
I understand we need to deal with that, but how critical is in terms of urgency. Moreover a potential new Node architecture could be rollup and this problem be tackle later or it must be addressed together?
This problem is a blocker to sunodo. The new architecture also solves this problem, but it will take some months to be ready. So, we could solve this problem with a simpler solution to Sunodo’s needs. We can design a solution that can be reused later in the new architecture or a solution that will only work in the older architecture.