Proposal: Support Twister Decentralized Research Organization

Proposal: Support Twister Decentralized Research Organization

Support Twister DRO to conduct open source research and to build useful blockchain infrastructure.

What is Twister DRO?

Twister DRO is the unofficial research division of Twister Cash. Twister Cash is an ambitious experiment in on-chain privacy, built on top of and expanding upon the foundational work of Tornado Cash.

Greater Scope of Interest

  • Verifiable Merkle Trees
  • Hash commitment and nullifier schemes
  • Groth16 trusted setup ceremonies
  • Socially and cryptographically trusted anonymity airdrops
  • Flashloan dynamics, including profitability and hacks
  • Lending market dynamics, including liquidation mechanisms and solvency
  • Privacy oriented governance mechanisms

Summary

The greater scope of interest contains our goals as they relate to the strategy and direction of Twister Cash’s development. As we attempt to build out a highly scalable token anonymizer, and as we generalize our components for more usecases, we plan to conduct open source research at the same time.

We’re making extra efforts to base our design decisions on well reasoned arguments and verifiable testing, and we think we will be more effective with public oversight and support from SCRF, which benefits users in the long run by ensuring the highest level of integrity and quality is given to the research and development of ultimately user-facing code.

One of the main goals of Smart Contract Research Forum is to bridge between two otherwise isolated areas: academia and industry. We see supporting Twister DRO as supporting a kind of hybridization of the two, and we feel that our work is in line with the goals of SCRF.

The ideal best case scenario of collaborating with Twister DRO would be standardizing a process by which independent research organizations can publicly execute on integrating cutting edge research while delivering useful products to global markets.

Description of Deliverables

  1. Informal LaTeX research papers written for technical audiences
  2. Blog posts describing results in laymen’s terms
  3. Periodic SCRF forum posts checking in to describe progress
  4. GitHub repositories with implementations and code used to generate results
  5. Some kind of (as of yet unknown) public hosting solution for large datasets
  6. Acknowledgement on the https://twistercash.xyz/ website
  7. Acknowledgement on social media and in public channels
  8. Acknowledgement in papers and on any media related to papers

How SCRF can support Twister DRO

  1. Grant funding
  2. Access to archival nodes
  3. Access to compute resources
  4. A GitBook pro subscription for our team
  5. Networking with independent researchers
  6. Spreading awareness of future results

We would like to have an public protected shared resource for blockchain data. For example, something like flashbots-mev-inspect. Much of the related work in pulling data on liquidations and arbitrage is already done, so we can leverage and potentially build on existing solutions to focus on our specific research questions.

Current Work

First Study: Verifiable Merkle Trees

The Verifiable Merkle Tree is a SNARK powered merkle tree. Merkle trees provide an efficient way to prove integrity about some data, e.g. that it actually exists in the tree. However, even in blockchain environments, merkle trees have their limits.

The limits on the use of merkle trees in blockchain environments are also limits on the privacy properties that a token anonymizer can uphold.

The rate at which insertions can be computed is constrained by how many insertions will fit within the block gas limit and by how much time it takes to process blocks. The maximum rate of computing insertions gives insight into maximum market size that can be served by a token anonymizer. The maximum rate of computing insertions determines the share of blockspace that a token anonymizer will have of the blockchain where it is operating, given a desired threshold of throughput.

The maximum rate at which the anonymity set can grow will be derived from the maximum rate of computing insertions, the maximum rate of computing proofs, and the maximum rate of verifiable updates that can fit within the blockchain constraints already mentioned. An insufficient rate of growth of an anonymity set directly limits the privacy properties of the token anonymizer. The actual rate at which the anonymity set grows can be used to reason about probability of privacy on a per-withdrawal basis. Having these parameters would be useful for users to compute wait times for their expected privacy threshold.

We can compare the scalability of the VMT to the needs of a global market, e.g. by comparing to VISA transactions or some other challenging standard. We suspect that the VMT will increase the scalability of a token anonymizer in such a manner that it can be a competitively powerful tool in many fields. We can explore workarounds to limitations, for example using deterministic transaction ordering to increase scalability by allowing sequential batch updates to be computed in parallel by a distributed network of nodes.

We have built a working prototype for the VMT. The VMT is a core component of Twister Cash’s redesigned token anonymity protocol. The current implementation lowers the on-chain cost of maintaining the merkle tree by over 10x, a significant improvement. Blockchains that define fees similarly to Ethereum should expect to see similar cost savings from adopting VMTs.

The VMT implementation we’ve presented uses a merkle tree of depth L = 20 and a batch size of M = 10 leaves (which is where we get 10x cost reduction). We can vary both parameters, and in general higher is better in both cases, except that higher values make the computations intensive which could lead to centralization of maintainence to only powerful servers.

Setting M = 100 could potentially scale the costs by 100x, but it might be unattainable with ordinary hardware. It would be useful to know what the largest batch size is as a function of hardware constraints.

Increasing L directly increases the maximum privacy threshold of the protocol, because that determines how many deposits can be inserted into the tree. For a tree of depth L = 20, depositors are roughly one in a million! The ideal value of L is 31, which could accommodate over a billion deposits. This limit is on a per-tree basis, so it isn’t a hard limit on the token anonymizer since we can just use multiple trees.

We can find some parameters that will optimize between the off-chain computational complexity and a more scalable tree size.

VISA can process ~600 million transactions a day, so that should be our impossible golden standard for a token privacy protocol, and we need to focus on the core cryptographic primitives if we want to achieve real scaling gains.

Disclaimer

We’re not seeking investments or selling anything. Supporting Twister DRO is not the same as supporting Twister Cash. We are seeking strict non-exclusivity with any partners, institutions, or organizations that support us.

Conclusion

With a maximally scalable privacy solution that is integrated directly into the base layer of the chain where it operates, rather than being an isolated rollup, and being combined with a fractional algorithmic stablecoin solution such as Frax, we imagine that in the future organizations will be able to deposit collateral, mint stablecoins into a treasury, and pay employees salaries anonymously using Twister Cash, and while their funds are deposited in the anonymity pool, they generate interest that trickles back to the organization, making Twister Cash an anonymity protocol, an innovative company-wide savings account, and an organizational accounting tool that facilitates secure decentralized collaboration by providing privacy for public ledgers.

We imagine that in the future and with the proliferation of cryptocurrency payments in every day life, people will enjoy shopping for their groceries and paying in crypto without getting accosted in the parking lot because their transaction revealed an entire financial history and the current networth and income level of the shopper.

Privacy is foundational to the utility of a digital currency, and lack of privacy is a hurdle to mass adoption. Overall our work intends to illuminate how we can build neutral infrastructure that will enable token anonymizers to become a core tool that empowers decentralized organizations to safely and securely pay contributors on global scale.

We expect that updates from our end will be sporadic but significant each time. We are interested in understanding what expectations SCRF will have from us as an unofficial group of independent researchers should we be offered a grant. As far as our timeline, there may be a buffer of several weeks before we return to this research endeavor, so there’s plenty of time for discussion around this proposal.

Happy to answer any questions or to go into more detail about any of the topics presented here today.

7 Likes

Thank you so much for this proposal! I am looking at the technical framework and wondering what informed starting the experiment with this line of approach? Was there an evaluation of other potential avenues for this type of experiment with Tornado Cash being the most viable starting point, or was this project specifically meant to build on Tornado Cash?

I am not questioning the viability, moreso I am trying to understand if this experiment is intentionally limited to the Tornado Cash framework as the basis, or were there other avenues for builds that were weighed before deciding on attaching this project to Tornado Cash?

Additionally: is there any regulation or rule as to why Twister researchers are hiding their identities? Is that a community mandate, team preference, or is it just coincidental?

3 Likes

Hello! Thank you for the thoughtful response. I’m glad you asked these questions, because it helped me to take a step back and contemplate things from a different perspective. I’ll answer this as an individual researcher and not as a representative of a research organization.

One of my goals in writing this proposal was to present a professional, competent research effort, one that is meritorious by virtue of the content of the study, rather than by the credentials of the researchers. I think that my strategy introduced unwanted mystery around the identities of the researchers.

My name is Justin. I’ve spoken with several members of SCRF via video calls. I’ve interacted most with @eleventh out of anyone at SCRF, and at one point I was considering the idea of contributing to SCRF by writing research summaries. I should be a familiar face to some at SCRF already.

There’s no community mandate, although my personal preference is to be identity-minimized, because I feel that in the event of any measurable success, I’d like to be able to separate my work life from my personal life, which could prove to be difficult otherwise. I have no interest in dodging accountability, and I hope that the details I provided in the proposal show how I expect to guide Twister DRO to transparently deliver on its goals.

The experiment here was informed specifically by building on Tornado Cash as a starting point, and I was hoping that would be a foundation rather than a limitation. My way of thinking around this is simple: as we build a specific use-case, we step out into the generalized form of the idea for the research, then we use that to justify the specific, which demonstrates applying the generalized form to a specific use-case.

Instead of writing a monolithic whitepaper that describes Twister Cash, I want to write several smaller papers on the core components in their generalized forms. I feel that these core components, (VMTs and commitment schemes mainly), if they are to be useful to the wider blockchain ecosystem, would be better served as standalone projects rather than as sections of the Twister Cash dapp’s whitepaper.

I suppose that the described process intends to overcome the limitation of being associated to a specific dapp by being broken into digestible chunks that individually are useful, and only when fully composed do they form the skeleton of Twister. I think that one benefit of associating the research to Twister is that it will give us an opportunity to explore how zero knowledge proofs can be used in production governance mechanisms (once we get to that point, which could be a while). I believe that privacy-focused governance mechanisms can use the same VMTs and commitment schemes we’re introducing for Twister Cash. If all goes well, then we would actually be implementing two different use cases using the same research results. I think that would ultimately strengthen the legitimacy of the ideas.

3 Likes

This all makes perfect sense. Thank you for taking the time to respond thoughtfully and with a clear line of logic behind all your actions.

3 Likes

No problem!

I’ve taken a proactive step and registered the twisterdro.com domain name. If SCRF decides to award Twister DRO a grant, then as part of our deliverables, we would point that domain name to an interface that displays information about the research–this could be using an existing solution, such as gitbook, notion, or something similar, or this could be a custom build frontend hosted on a cloud VPS provider.

If it’s better for SCRF, we can simply forgo acknowledgement of SCRF’s support on the twistercash site in favor of the twisterdro site, rather than directly affiliating SCRF with Twister Cash at all.

3 Likes

For the record, I am not against developers staying anonymous in general. Concerning grants, I do believe there is some merit in the notion of being able to establish a merit-based identity that doesn’t necessarily dox the individual without them having to completely reveal their identity publicly. It gets tricky to execute when money gets involved, but in general, I do believe that approach is something that would encourage some people to get involved that may be hesitant to reveal their identities for one reason or another.

It significantly helps the development of the forum if we have some explanations of why developers may want to stay anonymous or what would motivate them to at least get to a place where they feel comfortable dealing with the SCRF team without having to reveal their identity to the public at large. I did not want to put you in a position where you felt like you had to reveal your identity, but your response genuinely helps get perspective on how the forum can approach and receive people like yourself or others that might lean towards anonymity in general.

2 Likes

My apologies for my tremendous delay in following up. We’re still working on a process for reviewing such grant submissions so please follow up with me over discord (eugene#1706) or email (eugene@scrf.io) so we can discuss. Also, please let me know the size of support you’re seeking

1 Like