Application: Cyferio Hub

[moven0831]

Project Abstract

Please replace these instructions with a brief description of your project summarising key points (1-2 paragraphs).

If your application is a follow-up to a previous grant, please mention which one in the first line of the abstract and include a link to previous pull requests if applicable.

Grant level

• Level 1: Up to $10,000, 2 approvals
• Level 2: Up to $30,000, 3 approvals
• Level 3: Unlimited, 5 approvals (for >$100k: Web3 Foundation Council approval)

Application Checklist

• The application template has been copied and aptly renamed (project_name.md).
• I have read the application guidelines.
• Payment details have been provided (Polkadot AssetHub (USDC & DOT) address in the application and bank details via email, if applicable).
• I understand that an agreed upon percentage of each milestone will be paid in vested DOT, to the Polkadot address listed in the application.
• I am aware that, in order to receive a grant, I (and the entity I represent) have to successfully complete a KYC/KYB check.
• The software delivered for this grant will be released under an open-source license specified in the application.
• The initial PR contains only one commit (squash and force-push if needed).
• The grant will only be announced once the first milestone has been accepted (see the announcement guidelines).
• I prefer the discussion of this application to take place in a private Element/Matrix channel. My username is: @_______:matrix.org (change the homeserver if you use a different one)

[github-actions]

CLA Assistant Lite bot All contributors have signed the CLA ✍️ ✅

[moven0831]

I have read and hereby sign the Contributor License Agreement.

[keeganquigley]

Hi @moven0831 thanks for the application. Nice to see that you were already a winner in two hackathons. A couple of initial questions:

• The link to the Cyferio SDK gives a 404 error. Is this hosted in a different location now?
• On the Cyferio website, the docs and demo links don't seem to point anywhere.
• What is the expected latency and throughput of the FHE rollups, and how will they compare to traditional rollups?
• What mechanisms will be in place to prevent malicious actors from exploiting vulnerabilities in the cross-chain communication protocols?
• How will the integration with DragonflyDB improve the scalability and performance of Cyferio Hub, especially in terms of transaction throughput and latency?
• What are the expected limits on the size and complexity of confidential computations that can be performed on the platform?

[semuelle]

pinging @moven0831

[moven0831]

Hi @keeganquigley and @semuelle , thanks for the nice questions and reminders (sorry for missing the message). Our team have done some research and here are the responses to the best of our knowledge. Looking forward to your feedback!

Repo

we have refactored our github repo recently and are ready to open-sourced them. please check them on

• org page: https://github.com/cyferio-labs
• Cyferio Hub: https://github.com/cyferio-labs/cyferio-hub-node
• Cyferio SDK: https://github.com/cyferio-labs/cyferio-sdk (prev. tmc)

Website

the website is currently under construction. we will update it as soon as possible.

• Draft Web: https://cyferio.com
• Demo (Youtube): https://www.youtube.com/@cyferio

Benchmarks on the size, complexity, latency and throughput of confidential transactions that can be performed on the FHE rollups created by Cyferio SDK

We have done some benchmarks on confidential token transfers. This is done on single sequencer node and a consumer-grade machine. Notice that with production-grade hardware and increasing the number of sequencer nodes, the performance can be further improved.

• Machine Info
  • CPU: Apple M3
  • cores: 8
  • Memory: 24GB
• Single confidential transaction size: 75 KB (the transfer amount is a FHE ciphertext)

  Operation	Time Taken (seconds)
  Token creation	4.906156
  Token minting	9.091760
  Token transfer	5.951537

• Maximum confidential transactions in a batch: 4 Token transfers, or 75 KB * 4 = 300 KB size of transactions.

The details of the benchmarks are available here: https://github.com/cyferio-labs/cyferio-sdk/blob/d3a4601fa4d9f13301ce54a9144614e9cc796871/benchmarks/log_20241219.txt

Moreover, we want to highlight that Zama has done some benchmarks on the confidential token transfers. They have done it on production-grade hardware and the results shows that the performance of confidential transactions can be dramatically improved. With advancements in FHE algorithms and hardware such as GPUs and ASICs, we strongly believe confidential transactions will continue to improve in size, complexity, and speed, eventually reaching mass adoption.

Machine Info for Zama's benchmarks:

• CPU benchmarks: AMD EPYC 9R14 server with 192 cores
• GPU benchmarks: NVIDIA 2xH100

Table: Encrypted ERC20 transfers benchmarks

Hardware	Latency (ms)	Throughput (tx/s)
CPU	325	12
GPU	99	37

The details of Zama's benchmarks are available here: https://github.com/zama-ai/fhevm/blob/main/fhevm-whitepaper-v2.pdf

Comparison with traditional rollups

Compared to FHE Rollups, Optimistic Rollups have the following advantages:

• Lower gas cost (the transaction is relatively simple)
• Higher throughput: 10x to 100x of L1's throughput. e.g. 16 TPS on Ethereum Mainnet vs ~1000 TPS on Optimistic Rollups (reference: https://ethereum.org/en/developers/docs/scaling/optimistic-rollups)

Nonetheless, again, FHE Rollup is one of the most feasible solutions to have confidential applications achieve mass adoption without the need of upgrading the mainstream blockchains. On the other hand, the FHE Coprocessor approach is better suited for simpler applications, as it results in high latency and gas fees for more complex uses. And it's the only viable way to build comprehensive privacy-preserving dApps such as Confidential DEX, Confidentail DID and Governance since Cyferio SDK is highly modularized and can be easily customized for the needs of different scenarios to lower the cost of development.

Future mechanisms to prevent malicious actors from exploiting vulnerabilities in the cross-chain communication protocols.

We understand the concerns of the community and are actively working on developing mechanisms to ensure the security of the cross-chain communication. One way is to collaborate with a mature cross-chain communication protocol, such as those utilized within the Polkadot ecosystem, the team can leverage proven security measures (from Polkadot's shared security model) and established best practices that have been vetted by a broader community of parachains and relay chains.

Moreover, other feasible solutions are also being considered, such as diversified validator sets, robust smart contract audits, and secure key management are also in our roadmap.

Integration with DragonflyDB will improve the scalability and performance of Cyferio Hub in terms of transaction throughput and latency

Scenario 1 (FHE Ciphertext Transactions):

We leverage DragonflyDB to efficiently handle computationally intensive tasks. Specifically, in dealing with FHE ciphertexts and operations among them, its optimized memory management mitigates the high ciphertext blow-up rate (typically 100x to 1000x), reducing TPS and ensuring consistent latency. This enables Cyferio Hub to confidently scale encrypted transaction loads from FHE rollups.

Scenario 2 (Ordinary Transactions):

In terms of StateDB, compared directly to RocksDB that we've used for now, DragonflyDB's benchmarks show a superior QPS (queries-per-second), more efficient resource utilization with in-memory data store, all of which ensure that as transaction volume increases, performance remains stable and users experience minimal delays.