TORN Utility : Relayer Registry

TORN Utility : Relayer Registry

I would like to discuss a potential new useful update and torn utility with the community.

The relayer registry process could be decentralized and automated. Indeed, it would be possible for anyone to propose himself as a relayer. Furthermore, we could add an utility to the TORN token through this process.

Here is what could be put in place to become a relayer:
- Relayer would have to stake TORN to become a relayer,
- They will pay a fee on each processed withdrawal.

In case you like this suggestion/idea, we need to figure out some numbers:
1. How much TORN to stake to be a relayer?
2. How much fee a relayer should pay for each transaction processed?
3. Where do that fee go? (for example 45% to governance, 45% to LP on Uniswap, 10% to address(0) -> burn)

Do not hesitate to give your opinion and potential new ideas !

6 Likes

Time to revive this thread: Upcoming Relayer election mechanism

I agree that there should be a decentralized means of getting listed as a relayer. However, I’m not convinced staking TORN is the way to do it.

There’s really no way a relayer can act maliciously. Meaning, there is no reason to ever slash someone’s TORN. And having a requirement to slash usually precedes a need to stake. Ergo, we’d be introducing a staking mechanism arbitrarily. There’d be no need for it from an economic standpoint. And worse, it would create an artificial barrier to new community members preventing them from becoming a relayer if they don’t have the means to buy sufficient TORN. Right now adding relayers to the UI is centralized, but at least anyone can apply starting from nothing. I’d rather have the relayer process be centralized but open to anybody than decentralized and closed to some. Keep in mind I am a relayer, myself, and would benefit economically more from the latter.

Obviously, I am biased in this respect, as well, but I am also not sure that having relayers pay a fee does much exactly. It’s basically a tax on the user, but masked by saying we’re putting a fee on the relayer. Either way the cost gets passed to the user. We might do better to “tax” all withdraws, but as I’ve stated in the forums I’m not personally prepared for this. Although, I will admit I’ve basically surrendered to the fact that’s almost certainly inevitable. So I’m not going to fight it when it comes.

Additionally, there are instances when relayers actually lose money on their relays. They don’t get compensated for gas + their fee by the user appropriately compared to the amount they actually end up paying in gas. This doesn’t actually happen very often. It’s more of a fluke during volatile gas prices more than anything. But I bring it up to illustrate that the process of adding a fee to relayers is not perfectly so straight forward. Esp when compared to adding a fee to all withdraws.

If I had to propose an alternative means of decentralized relayer inclusion, I’d probably defer to using a token curated registry (TCR). If we used a TCR, then we could state that any address could be added as a relayer if they had x TORN staked upon them. That way they’re not the ones putting up the collateral, but it could be outsourced to the community. This could potentially be done gaslessly, like snapshot. But the benefit of this would be:

  • Anyone could become a relayer through an application process without already being a whale
  • It would create a TORN sink greater than having the relayer stake TORN themselves, since it would invite more people than just the relayers to ~lock up TORN to keep relayers on the TCR
  • It would not limit applicants from depending on the community, as a motivated applicant could be the one to put up the TORN themselves if they’d like/can’t garner the support of the community to vote for them
1 Like

That is why I think we should have a discussion, if we put in place a stake amount and a fee.
We can think about potential amounts, not forced to be a whale. In my opinion, this is quite interesting for the TORN token, as it will add an “utility”.

In general, I think that it would be a mistake to implement any functionality which causes TORN to be locked indefinitely, with a negative consequence associated with unlocking it (deregistration of your relayer). Such schemes would inherently reduce the amount of liquid TORN available for governance voting - unless the staked TORN remains available for voting on governance proposals.

I would also point out that by requiring TORN to be “staked” indefinitely, you would disincentivize people from running relayers, as the profit one could achieve by depositing it in an LP - or putting it to another use (e.g. borrowing against it for another asset that appreciates in value at a greater rate) - may be greater than the rewards from running a relayer.

What would make sense, however, is to use TORN deposits as an anti-abuse mechanism, similar to how proposals work. During your relayer registration proposal period, you should have to lock up some amount of TORN, for some minimum period. The purpose of a minimum period is to ensure that the interest cost (or opportunity cost) of borrowing/buying TORN purely to cover the cost of the proposal + buying yes votes is sufficiently high as to discourage people from flooding the registry with fraudulent relayer proposals.

What we need to balance is the need to have a sufficiently large number of relayers as to reduce the likelihood that any one relayer operator could be collecting information on relayed withdrawals, versus the incentive that someone might have to have enough relayers that they receive a disproportionate amount of the relayer rewards.

It might be worth considering a sybil resistance mechanism instead (or in addition), where relayers need to prove that they are a unique human not already represented amongst the relayer pool. “One relayer per human” is a fairly good control on abuse.

1 Like

I personally feel it’s shoehorning utility where there is none. Like there’s no actual problem being solved with staking. And even if we did do it, the amount of “utility” it would create is virtually nothing.

Let’s imagine we used 1,000 TORN or $50,00 at today’s rates as the required relayer stake - same amount as submitting a proposal. There are only like 10 relayers right now. That’s $500k out of $55 million diluted market cap ($500 million fully diluted). The “utility” created represents only 0.1% to <1% of the total liquidity. This would hardly move the value of TORN as a consequence.

Even if “utility” was entirely the goal here (and not decentralization of relayer registration), this proposal to introduce staking to relayers would not result in any meaningful measurement of success.

The goal with creating utility should not be to create utility for the sake of utility. It should be to find problems and solve them. If TORN needs to be used (or sometimes could be used) to solve that problem, then great! We have real, legitimate utility. But I do not see that as being the case here.

Ya, this is a perfectly reasonable consideration for decentralizing the relayer registration. Worth explicitly noting, however - as you already elude to - that this would not prevent sybil attacks as a person who already owns x amount of TORN to register their first relayer could then use that same x amount of TORN to then register a second after their first application is accepted.

I don’t know how we do this without KYCing people. And I am emphatically against KYCing anyone in the Tornado Cash community. It is literally an anonymity protocol - the only legit one in all of Ethereum. If we compromise the anonymity of the core infrastructure operators, then we threaten to compromise the anonymity of the protocol. Then, subsequently, that may threaten the anonymity of Ethereum users as a whole - the second largest blockchain next to Bitcoin (of course only by market cap; there’s an argument to be made that Ethereum is the largest blockchain in the world measure by actual usage)

1 Like

Indeed. However, it would mitigate concurrent registration proposals.

I agree that transparent KYC is not something that we want. However, we might be able to find a sybil resistance mechanism that preserves anonymity, or at least privacy. BrightID, for instance, is supposedly privacy-preserving, though I don’t believe that it’s anonymous.

I’ve been looking around a bit at whether anyone has developed an anonymity-preserving sybil resistance utility contract.

It might be something worth building out ourselves, using oracles to identity/reputation providers (e.g. Proof of Humanity, BrightID, Idena, etc) like GitCoin’s Trust Verification system, which feed into SNARK circuits.

On one side of the contract, you generate a commitment using an oracle which validates your identity with a provider and adds it to some sort of SNARK structure. On the other side of the contract, you can prove your unique membership in the pool of “identified by provider”, without actually linking your identity to your proof of having a distinct one.

It’d be especially useful if there were some way that the contract could generate a weighted reputation factor based on the types of identity providers you’ve used, and the number of them. This would make it less likely that people would use multiple different identity providers to generate multiple different identities, versus having a single identity which has connected multiple providers.

1 Like

Well, there would be many more if the Dev team didn’t mysteriously stop adding relayers, as there are many that are pending approval.

Execept for that one that was mysteriously added in June.

I would have a lot more confidence in Torn if the front end dev team wasn’t selectively choosing their friends as relayers.

I’m skeptical of identity systems in general. But if you can find something, I’m open to ideas. Providers are a cool concept in a zk based attestation system. I haven’t seen one implemented, yet, or at scales to obfuscate enough people within the provider’s system

This is fair

How so? I think while it demonstrates a limitedness to the community, I’m not sure if it actually reduces anything regarding the impact of TORN/Tornado

Well, there is a clear risk of Sybil attacks. Right now, the Tornado team has hand selected 10 relayers. We have no idea how many of those are actually the same person.

Each of these relayers can be maintaining access logs to cross reference IP addresses to ETH addresses.

The Tornado team could trivially add 10 more relayers who have been pending for over 6 months.

But they choose not to. Why? It is a red flag for privacy and Sybil resistance in my opinion.

Something isn’t right.

I hear what you’re saying and agree relayer registration needs to be opened

But even if they are the same person… what happens then? There’s not really much of an attack vector that opens up as a result. Other than one person could be accumulating more fees than the rest

This would be a possibility even with a distributed registration though. There could be 1000 relayers and you would never know who is keeping logs and who isn’t. Best thing to do as a user is protect yourself with a disposable browser (and possibly device), isolated wallet(s), and VPN with rotating IP addresses (or tor)

I’m operating a relayer, and for what it’s worth I’ll say I have a reasonably high confidence level that a majority of the relayers are different people (some are publicly identifiable). That said you shouldn’t have to trust my word for it, and it’s possible I could be wrong

I believe they choose selectively because they are onboarding relayers who they can reasonably trust to not log users’ IPs (by identifying them as existing, active community participants)


All that aside, I want to say again: I do think it’s worth pursuing a more open registry system. I don’t want to give off the impression I’m trying to keep the registry closed - presumably because I’m already on it and would benefit from it remaining closed. Obviously, I am incentivized in that way, though. So I can really only try my best to be unbiased here. If anyone believes I’m not being fair or I’m having any blind spots in my reasoning, I kindly invite them to provide me with proper feedback. DMs are welcome, as are public forum responses in this thread or others.

My primary intent to replying to the above comments is that I wish to calm some of the statements of urgency. Yes, we do need to fix this problem of the relayer registry, but the protocol and its users are not fundamentally at risk while we work to solve it.

Now let’s try to come up with some solutions:

  1. The community could create a tornado.cash clone interface at another domain that hosts a community curated registry of relayers - keep in mind anyone can run a relayer. The only barrier right now is getting listed on the interface
  2. The tornado.cash team could allow for multiple relayer curation lists to be available on the main tornado.cash interface. The default list might be “Tornado Curated Relayers” but users can toggle to a much more open “Community Curated Relayers.” This would be similar to how Uniswap curates their token lists (Uniswap’s list is the default and other communities create their own curations, as well)
  3. If either 1 or 2 can be executed safely and effectively, then maybe the “Community Curated Relayers” could become the default on tornado.cash

Then, what’s the point of having relayers? I’ve become more and more convinced that relayers aren’t actually doing much of value for users. On passing inspection, they seem like they add to anonymity, but when you look at the details of how they work, and the fact that they’re probably operated by a small number of people, they actually seem like a huge liability.

The reality is that a gateway like Infura is less likely to be compromised by adversarial interests than the individuals running relayers. Users would be better off submitting their transactions directly through a gateway, than using a relayer.

The only true value that relayers seem to provide right now is to front the ETH for withdrawals. If we could pare the relayer system down to exactly and entirely that function, and remove all notions of them being some secure gateway to the network, that would be immensely better.

Who’s running the software isn’t even the biggest concern. There are other big concerns like, where are they running the software? Are the relayer nodes running in the US or China? Which ISP are they using? How secure is the environment they’re running in? Has anyone pentested them?

Would you volunteer to have your relayer audited/pentested, as a demonstration?

That’s not a good way to establish trust. I have no idea who any of you are. I don’t know who you work for. I think that it’s foundational to crypto that you should never trust anyone with anything valuable or sensitive.

Tornado.cash as a project should focus on verifiable security, not reputation and trust.

Yes and no. Yes, they front the ETH. But you could front ETH from any other wallet you own. You don’t need a relayer for that.

More specifically, relayers allow virgin addresses to be seeded with a fresh, anonymous withdraw without connection to any other address you own. You’re making a request of a “stranger” to make the withdraw for you so you don’t transparently destroy your own entropy.

Again, though, you can protect yourself sufficiently as a user by shielding your own interaction with a relayer (VPNs, tor, etc), so not even a relayer can compromise you if they wanted

Relayers are only a liability if you let them. Use good opsec

iirc there’s talk of getting rid of relayers for v2

If you would like to recommend a procedure of audit that would provide persistent reassurance, I would be open to it. Sure

But I really think you’d find more reassurance maintaining your own hardware/OS/browser/ISP opsec than trusting a one time audit that really cannot guarantee a relayer maintains the specs of the audit after the audit has concluded

As in: I could be running spyware, remove the spyware, get audited, pass, and then put the spyware back

You understand I’m agreeing with you, right? I offered a few solutions to wean ourselves off the centralized relayer curation problem. You’ve made your frustrations clear. I hear you. But if we don’t have an alternative, then I’m not sure how we move forward.

What we can do is:

  • use what we have now while maintaining good hardware/OS/browser/ISP opsec as users
  • come up with an alternative plan that we can eventually migrate towards (v2 or other)
  • execute on that plan and migrate to it after it’s been tested, audited, etc

I do understand that, yes. I’m not frustrated at you or the project, as such. The frustration in my tone is entirely about my passion for what I believe are TC’s ideals, and how the current solutions fall short of meeting them. An idealistic frustration, if you will. :slight_smile:

I’ve laid out a potential solution in another thread, which would solve a lot of the current problems with relayers. Hopefully it’s feasible.

Agreed. I think that overall, my point in this respect is that the narrative around how relayers function should be adjusted to make clear that they provide no privacy guarantees in terms of mitigating network-level surveillance. They’re only useful for the first note withdrawal, for fronting gas.

Users should be advised to always use tor when withdrawing, if they wish to maintain any true semblance of anonymity.

3 Likes

I support that

I saw. Appreciate you putting forward a potential solution like that. I’m going to refrain from commenting on there for a little bit to give others a chance to comment first

Correct. They enable privacy guarantees. But you must be willing to combine it with your own opsec in order to inherit them

Exactly

And if we’re on this line of thinking - and if we’re not already paranoid enough - then it’s worth pointing out that most users’ hardware and OS are a complete point of vulnerability, as well. Anyone interested in this should follow the work of Andrew “bunnie” Huang:

1 Like

While it seems like the relayer system is safe from sybil attacks (privacy concerns notwithstanding), and thus it probably isn’t necessary to require some TORN minimum stake, TORN as a staking token could be useful to determine which relayers are listed in the UI (and in what order).

It is a pain for users when relayers are down and they have to try other relayers. Maybe we could solve this with some tokenomics…

Consider using something like the Cobb-Douglas production function as it is used in 0x and The Graph. TORN holders could delegate to certain relayers, and receive a portion of their fees (no stake required for relayers themselves). The UI could sort the list of relayers by delegated stake, with number 1 being the default (or you could try to add some randomness to the choice of default, weighted by delegated stake).

TORN delegators would perform the function of determining which relayers are likely to produce the most fees (presumably due to reliability and accurate gas-price predictions).

1 Like

Would you explain to me the privacy concern you refer to? I posted in another thread but no one replied. What information can a relayer capture as it relates to the transaction and de anonymizing? I see posts all the time discussing relayers can not alter or steal the funds but that is only one issue. If the relayer actually can intercept information that would allow transactions to be traced then I can guarantee that blockchain analytics companies would/have sign(ed) up to be relayers.

1 Like

So I’ve been following this conversation since it really picked up again and dug into the 0x rebate program. For context, I am currently developing a solution similar to the ideas posted in this thread for torn staking.

I went through the above paper, and the logic seems great and pretty well compatible with our current system. Our production can be thought of in terms of our relayers fee accrual and delegated stake.

I will check the results 0x had with this program and research a little more into it, to specifically see how gas-efficient they implemented this (apparently they managed to handle this with a single variable update in an order but have to see how this is applicable to our usecase).

Their system also distributes accrued funds periodically rather than automatically, so that is a thing to keep in mind.

So yes, very interesting and thank you for the information.

2 Likes