deroproject / dips Goto Github PK

DVM(DERO Virtual Machine) Enhancements

Suggestions are invited for inbuilt functions for DERO Virtual Machine DVM which will enhance DVM and take it closer to some real use cases.

DERO Virtual Machine (DVM)

DERO Virtual Machine represents entire DERO Smart Contracts eco-system which runs on the DERO block chain.

Read more about DVM and DERO Smart Contracts.

• Dero Virtual Machine
• DVM DOCS
• Dero First Smart Contract
• Other Smart Contract Examples

DVM Documentation

DVM is a decentralized platform that runs both public and private smart contracts: applications that run exactly as programmed without any possibility of downtime, censorship, fraud or third-party interference.Public Smart contracts are open versions. However, the DVM is being designed to support Private Smart Contracts where everything is hidden, eg parties, and information involved. Smart Contracts are nothing but rules which apply on transacting parties.

Current version of DVM is an interpretor based system to avoid security vulneribilities, issues and compiler backdoors. This also allows easy audits of Smart Contracts for quality,bug-testing and security assurances. DVM supports a new language DVM-BASIC.

DVM apps run on a from scratch custom built privacy supporting, encrypted blockchain, an enormously powerful shared global infrastructure that can move value around and represent the ownership of assets/property without leaking any information.No one knows who owns what and who transferred to whom.

• This enables developers to create puzzles, games, voting, markets, store registries of debts or promises, move funds in accordance with instructions given long in the past (like a will or a futures contract) and many other ideas/things that have not been invented yet, all without a middleman or counterparty risk.

• DVM-BASIC is a contract-oriented, high-level language for implementing smart contracts. It is influenced by GW-BASIC, Visual Basic and C and is designed to target the DERO Virtual Machine (DVM). It is very easy to program and very readable.

• DVM runs Smart Contracts which are a collection of functions written in DVM-BASIC.
  These functions can be invoked over the blockchain to do something. SCs can act as libraries for other SCs.

• DVM supports number of comments formats such as ', // , /* */ as good documentation is necessary.

Example Factorial program

' This is a comment
// This comment is supported
/* this is multi-line comment  */
 Function Factorial(s Uint64) Uint64   // this is a commment
	10  DIM result,scopy as Uint64     /* this is also comment */
	15  LET scopy =  s
	20  LET result = 1
	30  LET result = result * s
	40  LET s = s - 1
	50  IF s >= 2 THEN GOTO 30
	60  PRINTF "FACTORIAL of %d = %d" scopy result 
	70  RETURN result
End Function

DVM are written in a DVM-BASIC custom BASIC style language with line numbers.

DVM supports uint64 and string data-types.

DVM interprets the smart-contract and processes the SC line-line

• uint64 supports almost all operators namely +,-,*,/,%

• uint64 support following bitwise operators & ,|, ^, ! , >> , <<

• uint64 supports following logical operators >, >= , <, <=, == , !=

• string supports only + operator. string support concatenation with a uint64.

• string supports ==, != logical operators.

• All DVM variables are mandatory to define and are initialized to default values namely 0 and "".

A SC execution must return 0 to persist any changes made during execution. During execution, no panics should occur.

This github issue is created to record suggestions of new features and improvements.

Please use this thread for NextGen Blockchain Features Proposals.
Feel free to include P2P, privacy, mining etc. anything related to requirement/mass-adoption/usage of futuristic blockchain like where common man and IOT devices are utilizing blockchain in day to day life with full privacy and without any hype.

Take this thread as beyond DERO, it is about futuristic blockchain.

DERO-HE is having following features right now.

DERO HE Current 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 scalability[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)

Requirement of 1 account = 66 bytes
Assuming storage overhead per account of 128 bytes ( constant )
Total requirements = (66 + 128)GB ~ 200GB
Assuming we are off by factor of 4 = 800GB

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.

Suggestions are invited for following:
POW Mining ALGO for CPU & GPU support with ASIC/FPGA resistance.

Please share your suggestions, expertise, papers etc. to develop above algorithm.

Update 1 Source code released