Upcoming Relayer election mechanism

The Tornado cash team has came up with a new set of contracts:

The goal is to move away from a centralized/permissioned system for the official relayer list to a governance lead one. Currently, the front-end maintainers just pick random people from the community to operate re layers. The core idea of this new contract is:

  • Relayers are voted in or out through governance proposals
  • Relayers need to provide a TORN stake

Let’s start to gather feedback on this new system.

I have the following comments on this contract:

  1. To add/remove relayers we would abide to the same voting threshold as for any other proposals changing the protocol. Maybe relayers will need to be changed more often.
  2. Should we consider a slashing mechanism of the TORN stake for malicious/unreliable relayers ? This would create some sort of economics guarantees.
5 Likes

It is very hard to prove bad behavior onchain. And relayers can’t be malicious anyways, worst thing they can do is not doing their job, they can’t modify any data. They could also set an unusually high fee hoping users won’t notice, but this can be solved with a warning on UI.

If a relayer takes requests but don’t submit them too often governance can kick him out of relayers lists.

2 Likes

Additionally to what was proposed, I would also like to suggest that instead of each relayer being paid on every relayed transaction, maybe it would be fair that all fees go to an address that later (end of epoch, month, etc) is distributed by all relayers regardless of the # of transactions, but instead, by the accuracy (% of concluded vs proposed jobs)

For this to be possible, the same voted fee would be applied by all nodes which would end being more fair and safe for the end user.

The TORN stake should also be considerably high, similar to what REN relayers pay to have the darknodes ($63.000 in token at today’s prices). This is important to ensure that only people committed to the project are rewarded accordingly.

my 2 cents :slightly_smiling_face:

2 Likes

Welcome @acegilz and @poma to torn.community!

I know, what I had in mind was just a governance only function that confiscate the stake (burn or send to treasury). It can be a powerful deceptive effect. But simply kicking out relayers might do the job well enough.

My point is, in general proving stake is useful because it provides economic security for a system (= I won’t misbehave because I have money at stake). If the assumption is that they are no misbehavior possible in the first place, there is no point putting up stake beside showing support to the TORN token.

Same comment as Poma. You can’t evaluate that on-chain. So it would be a managed system with an arbitrator or something. I guess we don’t want that.

1 Like

This also provides some sybil resistance.

4 Likes

when are you guys planning to deploy this contract? everything seems good from the github repo, and also from what i understood, the idea is to switch to this decentralised relayer system asap, right after torn is tradable, right?

I can’t comment on the contract if it’s ready + tested + audited. But once it is, we will need a second governance proposal to swap the contracts. We first need to pass the enable transfer proposal I believe.

1 Like

lets go?? the torn proposal is already on its way to implementation @Rezan

I don’t know if it’s ready yet. I would wait for the team to answer that.

What is the logic of needing to have a voting for each new relayer to be added? I suggest removing the following 2 lines

// function add
require(msg.sender == governance, "unauthorized");
require(!isRelayer[_relayer], "The relayer already exists");

If we struggled to have a quorum of 25k to activate the TORN transfer, I wonder if we’ll ever have a new relayer with the current proposal… No one will vote for it.


Also, to avoid having to create a new proposal right after this one is approved just to call the setStake, I suggest that we pass a stake value in the constructor, right at this same time this proposal is implemented.

We have TORN trading at around $150, so for example 50 TORN may be a fair value ($7500) to start, and then we can always adjust it later via proposal, if necessary.

1 Like

This also provides some sybil resistance.

Barely

The benefit of providing what is effectively an unnecessary degree of sybil resistance really doesn’t outweigh the cost of making relay operation a cost-prohibitive endeavor.

I’d rather we encourage relay operators to compete on bases other than whether or not they are a whale

1 Like

Why not boardcast the withdraw params so that anyone can help withdraw while ensuring anonymity

1 Like

User can set the reward & tx fee for the volunteer

1 Like

@su_root that’s actually brilliant!

100x support this

This is a neat idea, but it would have negative consequences for privacy.

All relayers know the IP of the submitter, as opposed to just one. Analysis firms will monitor this relay network and keep records. The relay network would need to live only on tor to prevent this, but then it would also require users to connect to tor.

Also, this requires a relay network as a whole which does not yet exist.

1 Like

I would tend to agree that it is going to be very challenging to elect relayers.

Is the goal that only whales get to be relayers?

Wow. Didn’t realize

So is this all just privacy theatre until we have tor relayer options, then?

Absolutely should not be optimized for whales. Should be optimized for highest level of privacy

How do we create trustless relayers?

If relayer network is trustless first and then it turns out whales are the only ones who can then afford to operate, great. Then it’s skewed for whales. That’s fine, but only if privacy is #1

1 Like

[quote=“acegilz, post:10, topic:28”]
What is the logic of needing to have a voting for each new relayer to be added?[/quote]

Agree, it should be changed so that anyone that posts TORN stake can become a relayer.

1 Like

We tried to do this in the initial relayer network design but this approach has a lot of problems. If the fee goes msg.sender, relayers start to frontrun each other and also compete with generic frontrun bots. In the end only a single transaction goes thru and all others revert and relayers lose funds. We were unable to solve those problems and went with different design where a user has to choose which relayer gets the fee in advance.

The problem is, if someone posts a transaction on chain, he will likely gets frontrun by bots and loses fee, but if nobody posts this transaction the frontrunners will never know about it. In theory frontrunners can be used as a relayer network, if we find a way to broadcast transactions to them without losing funds on reverts.

1 Like