DERO future approach disccussion

General Discussion
#1

Hello Everyone,

DERO is working on DERO-HE with following features:

  1. Homomorphic account based model [First privacy chain to have this.](Check blockchain/transaction_execute.go line 82-95).

  2. Instant account balances[ Need to get 66 bytes of data only from the blockchain].

  3. No more chain scanning or wallet scanning to detect funds, no key images etc.

  4. Truly light weight and efficient wallets.

  5. Fixed per account cost of 66 bytes in blockchain[Immense scalability].

  6. Perfectly anonymous transactions with many-out-of-many proofs [bulletproofs and sigma protocol]

  7. Deniability

  8. Fixed transaction size say ~2.5KB (ring size 8) or ~3.4 KB (ring size 16) etc based on chosen anonymity group size[ logarithmic growth]

  9. Anonymity group can be chosen in powers of 2.

  10. Allows homomorphic assets ( programmable SCs with fixed overhead per asset ), with open Smart Contract but encrypted data [Internal testing/implementation not on this current testnet branch].

  11. Allows open assets ( programmable SCs with fixed overhead per asset ) [Internal testing/implementation not on this current testnet branch]

  12. Allows chain pruning on daemons to control growth of data on daemons.

  13. Transaction generation takes less than 25 ms.

  14. Transaction verification takes even less than 25ms time.

  15. No trusted setup, no hidden parameters.

  16. Pruning chain/history for immense scalibility[while still secured using merkle proofs].

  17. Example disk requirements of 1 billion accounts ( assuming it does not want to keep history of transactions, but keeps proofs to prove that the node is in sync with all other nodes)

  18. Note that, Even after 1 trillion transactions, 1 billion accounts will consume 800GB only, If history is not maintained, and everything still will be in proved state using merkle roots. And so, Even Raspberry Pi can host the entire chain.

  19. Senders can prove to receiver what amount they have send (without revealing themselves).

  20. Entire chain is rsyncable while in operation.

  21. Testnet with above features released with source code.

  22. DERO-HE will be able to send a reply back within TX to sender back with full privacy.


With new learning, insights, development and technologies like GravitonDB some new features and use cases have been discovered to move forward with development plan. Please see following two future approaches.

[1] DERO-HE will be able to send a reply back within TX to sender back with full privacy. With this feature users can run and provide services like creating their own native market just using DERO Network without use of any external/third-party support. Users would be able to sell their software-licenses,keys etc. using 128 bytes space allocated within TX. Transactions between seller/buyer will be perfectly anonymous due to many-out-of-many proofs [bulletproofs and sigma protocol].

Anonymous voting systems and OTP services can be created natively using above functionality. Users need to create such services using RPC-API/Websockets provided through their local wallet interface. Users are free to use any language like Golang/Python/PHP/C etc. to handle incoming transaction and create reply.

DERO Network will be very light-weight as network has to handle 128 Bytes extra only with fix predictable computational load. In this approach DERO Network can truly serve and handle billion accounts and bring million users to blockchain with hundreds of true real use cases with full privacy.

Any light weight computing device can connect to DERO Network using even Raspberry-Pi/old firewall/routers, USB computing devices etc. This will be truly private platform in itself with lots of opportunities.

[2] Some users feel DERO Virtual Machine should run on chain to avoid trust issues as service provider wallets uptime cannot be guaranteed and controlled in above approach. DVM-SC have use cases like crypto-kitties,lottery,token-ICO launches etc. with full privacy. DERO Basic Smart Contracts code will be open on chain and assets after transferring to wallet will be hidden like main DERO balances.

This second approach will create heavy computational load on DERO Network and will make it slow and heavy just like other existing blockchains.

Suggestions and discussions are invited to adopt future path for DERO Network.
Discussion of pros/cons of both approaches are appreciated.

Captain.

7 Likes
#2

The main objective of DERO was private Smart Contracts. We have to keep this goal in mind so as not to throw away all the work done for this one. They will thus allow the development of dApps such as Multisig, DEX, Auctions, Marketplace, decentralized chat room, tokens and many other use cases.

Keep Stargate V1 Private Smart Contracts and run them on “SC Validator” only.

Since the necessary computation is heavy, the Smart Contracts will not be executed by the entire network, but only by a part, allowing users to choose whether or not they wish to run the SC and to have the best possible speed on DERO-HE.

The SC Validator is a full node that can execute and save Smart Contract. They will be the only nodes tthat perform computation for the Smart Contracts. To ensure the honesty of a node, it must lock an amount of DERO that can be destroyed in the event of a deliberate error or attack. In exchange for the work provided, SC Validators will be able to receive a DERO reward based on the cost of the computation of a SC.

Example:
to reward the SC Validators, would it be possible to be paid for the necessary calculations ? Example: a SC (named A) require more computation than another SC (named B), executions fees will be higher for A than B.
And SC Validators are rewarded using executions fees, (and not mining blocks/normal tx! we keep this task for miners)

DERO will therefore have two main functionalities: Services and Smart Contracts.

5 Likes
#3

I believe that smart contracts on layer 1 are essential to create apps that do not rely on trusting individuals. If we must choose one option over the other, then I think this should be the way forward for Dero, as has been the goal from the beginning. But I can also see the massive benefits of a fast and lightweight blockchain for use cases that involve payment only, or services which require a lower level of assurance. So how about a third option: have two separate blockchains under the same umbrella project. One that supports SC’s, and the other fast and lightweight. Captain has developed the tech for both possible futures: let’s do both.

I am putting together a full write up which will go into detail on my reasons for this suggestion, but it is taking a lot longer than I thought. I will aim to post in the next few days.

5 Likes
#4

Each line written in above paragraph can have multiple Ph.D and yet then fail to run with success. Above concept has numerous flaws.
For Eg:

  1. What are SC validators and how blockchain/node will identify that they are validators ?
  2. Definition & Identification of attack in Algorithm.
  3. Whole chain had to wait for any SC to finish to update DB. So speed set by SC executions.
  4. Numerous others…
2 Likes
#5

I strongly believe that the best path here is to think of both the DERO daemon, miner, and wallet as three aspects of a single platform. A user interacting with the platform may choose to deploy each of these aspects, but they should also be able to deploy their own “aspects”, building on the base DERO HE chain. This perspective is just a generalization of the view of Slixe above. Why should a Service be limited to being a wallet plugin? Why not a daemon plugin? My answer is: both daemon and wallet are special services (exposing APIs), and other software can interact with those APIs; both daemon and wallet should be thought of as plugins for the DERO Platform. Similarly, a 3rd-party Service hosted by the platform would also expose an API, and possibly interact with the APIs exposed by other services (such as the wallet and node APIs), and thus interact with the base DERO HE blockchain.

In this architecture, the daemon has the job of implementing Captain’s approach [1], as well as possibly any extra support code required to enable 3rd-party services in the daemon and wallet. Then, I propose that the DERO platform also delivers an optional DVM service (implemented as a platform / node plugin). The database for the DVM service would be separate from the base DERO HE blockchain DB. DVM execution fees would be paid with DERO, and the DVM service would take advantage of the DERO-HE “homomorphic asset” functionality. Smart contract consensus would be ensured by a 2nd-layer algorithm such as proof of stake or proof of diversity or proof of transfer. DVM TXs would be encoded within the “extra data” of base layer TXs. We should think of this model as an “overlay” blockchain, or “internal” blockchain. In this model, the base chain remains light, but users can run the DVM service to receive computation rewards (fees) as well as to interact with smart contracts.

It is totally clear to me that DERO should implement some smart contract feature. The number of use cases enabled by smart contracts is much greater than those enabled by mere wallet-to-wallet services: auctions, marketplaces, multisig wallets, DEXes, stablecoins, etc, are all valuable and valid use cases. The world is desperate for a usable private SC platform. Moreover, if DERO abandons the smart contract vision, then it is unlikely to be adopted anyway, because of the instability of the vision, and the present lack of demand for wallet-to-wallet services. By implementing smart contracts, DERO can attract real world usage, which may lead to more adoption of wallet services. But adoption of wallet services will not come first, regardless of their technical merits. “OTP services running on old routers” is just not sufficient: we need more compelling use cases than this.

EDIT: I have just seen the reply to Slixe above, and will consider a response. It does not seem to be the case that, in the architecture I have described, the base layer would have to wait for SC execution. SC execution is independent of the base layer. The base blockchain does not have to identify SC validators, because the base layer is unaware of their existence. SC validators identify themselves by seeing “magic” data encoded in TXs, or API calls to services exposed by RPC.

EDIT2: My personal preference would be to see the DERO HE base layer released to mainnet, possibly with minor alterations to enable to above vision. It will be easier to define rigorously what is possible when the full platform details are known. Then a DVM overlay service can be implemented subsequently.

6 Likes
#6

Release DeroHE to mainnet first and improve sc later.
Take a look at Verifiable HE, if it can be implemented performance and decentralization will be improved.

1 Like
#7

As stated above me, Would love to see DERO-he on mainnet. as many others would but will not respond here.

#8
  1. SC Validator is a full node having locked X DERO coins. We can save the list of SC Validator in the blockchain.
  2. To prove the honesty of a node, they lock an amount that they can lose by trying to attack/produce a fake result.
  3. Not whole chain would have to wait for any SC to finish because only SC Validator execute SC and send back a TX to the network with a “summary” of what should be updated.

All the network execute the TX like any other normal TX, but SC Validator execute the SC and the result to the network.

That mean, SC Validators (nodes) on the network can be listed, but others “normal” nodes stay still private.

And as another solution, wouldn’t it be possible to have Smart Contracts executed by miners?

#9

A possible architecture for a DVM overlay chain is given by rollups: https://vitalik.ca/general/2021/01/05/rollup.html

Note the following remark (with respect to dApps): “The fact that data is on-chain is key (note: putting data “on IPFS” does not work, because IPFS does not provide consensus on whether or not any given piece of data is available; the data must go on a blockchain). Putting data on-chain and having consensus on that fact allows anyone to locally process all the operations in the rollup if they wish to, allowing them to detect fraud, initiate withdrawals, or personally start producing transaction batches.”

I am sure some intermediate architecture can be reached using something like rollups encoded in service TXs on DERO-HE. But I do think the priority should be getting DERO-HE with homomorphic assets and services on mainnet, possibly with minor modifications to enable a DVM-service. (Some more use cases for pure services: payment for content DRM keys on a federated service like PeerTube; payment for IPFS storage; a centralized stablecoin like Tether (assuming homomorphic assets)…)

#10

DERO Homomorphic Encryption(DHEBP) + DVM-SC onchain is being worked upon.
DVM will use DERO BASIC as released in previous StarGate on CryptoNote Protocol.
Testnets with both approaches are being developed and community will decide whats best for future.
We can expect testnet next month if all goes good and no unforeseen technical challenges.

9 Likes
#11

i have a possible solution. what about put the DVM in dero wallet?

wallet could be used as node validator and/or sc executor. sc and global state are stored onchain but when u need to interact with them u “download” the sc and global state, execute it in ur wallet, broadcast the tx with sc hash execution, compare onchain with other part, validate if is the same and edit the new global state.

in this case is possible not to congest the nw and keep the scalability. is it possible?

If sc are executed offchain not need fhe. Only onchain operations needs fhe.
At the end is to move value from a to b or viceversa onchain that need fhe. SC execution “create” the tx schema to be executed onchain with fhe

#12

[A] With all inputs, It has been decided that DERO will move ahead with original DVM Smart Contracts(StarGate) only . As DERO community has already invested lots of time and resources on DVM-SC, there is no point in changing plan.
[B] DERO other approach is new and needs lot more evaluations and developments which may lead to further delays. New approach will be re-evaluated in future after some more developments and improvements in the service structure.

See following to go through about DVM SC which were released on DERO-Atlantis(CryptoNote Protocol). Upcoming SC will follow similar structure.
DERO Virtual Machine
DVM DOC
DERO First Smart Contract
DERO Smart Contract Examples

7 Likes
#13

DERO STARGATE RELEASED with both DVM and Service model.

6 Likes
#15