DERO Virtual Machine Inbuilt Functions Suggestions

[CaptainDero]

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.

[CaptainDero]

Read and learn more about DERO DVM and Smart Contracts on stargate testnet.

[lory7741]

IDEA FOR DVM:

• loop while/for (without goto if possible)
• remove line number in syntax (turbo basic syntax)
• possibility to call/interact with other SC
• libraries/functions to call extarnal blockchain data
• true random number
• local DVM compiler/simulator to check SC
• arrays and hashtable (very important!) with relative functions
• funtions for strings (ex. strlen, concat, substring,...), numbers (random, min, max,...)
• date/time functions (very important!) not the approximation of blocktime to calculate time
• DVM CRON to trigger SC at specific time/block
• classes/objects for an OO developing
• methods (public, private, static, ... ) for variables and functions. this is important in case of interactions with other SC
• exceptions in case a problem that arises during the execution of a SC
• DERO DNS for wallets/SC (change the address with a unique name)

IDEA FOR DERO PROJECT:

• oracle for external blockchain data (CHAINLINK)
• plugin for note++, eclipse, netbeans, ..... to import DVM syntax highlighting/marker and popup call functions

[lory7741]

about random number, is it possible to use next tx block hash to create the random number?

i found also an interesting paper about random number on bitcoin

2015-1015.pdf

1902.07986.pdf

WEBSITES:
https://www.ginar.io/
https://www.cloudflare.com/leagueofentropy/
https://blocking.net/7155/ethereum-2-0-randomness/

[Nelbert442]

While we did come together and make functions for errors and returning balances when they occurred during testing earlier this year, I know there was once discussion about solving this issue to where if a SC errored out, the sent value(s) would be returned.

just to expand on what I was mentioning, I know one example was this and I believe others had some other similar versions as well:

error function: https://github.com/Nelbert442/DERO_Stargate_SC/blob/master/timebox_payment.bas#L28

the call of the function supplying value as a parameter: https://github.com/Nelbert442/DERO_Stargate_SC/blob/master/timebox_payment.bas#L87

[Slixe]

• Hash algorithm functions
• type structures
• Current total supply function
• Current SC Balance function
• arrays/list

[ghost]

• Dictionary && List data structure,and 'For loop' to enumerate Dictionary or List variable.
• Encrypt& Decrypt function based on dero address and seed(private key)
• Output from SC,trigger external API on internet
• Some more functions to get blockchain data like block height and block hash or so

[lory7741]

DERO API/SDK for dapp developers

https://www.programmableweb.com/category/blockchain/sdks

examples:
https://github.com/eosio/eosio-java
https://developer.samsung.com/blockchain/platform

[Lebowski1234]

Hashing functions:

SHA-256
Keccak-256

Also function to convert string to bytes for input into hashing functions.

[pojira]

BLOCK_TIMESTAMP := get the unix time (uint64) of a block from within a smart contract

rationale:

alongside BLOCK_HEIGHT, it would be useful to have BLOCK_TIMESTAMP, because block times can change and it's useful to make smart contract actions conditional on time

as a concrete example, I'm looking at implementing a 'Harberger tax' smart contract for digital asset ownership, in which owners periodically engage in a kind of auction. but i don't want the auction period to be dependent on the block time.

something like BLOCK_HEIGHT that just returns the unix timestamp of the last block would be ideal: the condition would be something like "on the first block after timestamp T, allow [or disallow] action A".

action A would be something like "user makes a bid", but only within a particular time window.

[pojira]

VALIDATE_SIGNATURE(DATA, SIGNATURE, ADDRESS) := returns TRUE if SIGNATURE is valid from ADDRESS on DATA, otherwise FALSE

rationale:

to perform smart contract actions on the basis of external data, it will often be necessary for some 'oracle' to supply the data. but we do not want to bloat the blockchain with storage of this data. alternatively, we can have the oracle sign the data (DATA) with a private key corresponding to a dero address (ADDRESS). the smart contract user can then supply the data DATA and the resulting signature SIGNATURE in the relevant smart contract call, and then the smart contract can validate the data by checking that the signature is valid using VALIDATE_SIGNATURE. the smart contract can then perform the desired action without requiring DATA to be stored by the oracle in the on-chain database.

[pojira]

I also second the suggestion for permitting smart contract functions to call functions from other smart contracts. This allows some contract to supply services to other contracts which can consume them, and is a key ingredient in the vibrancy of the Ethereum ecosystem. See the links below.

A related feature is the ability on Ethereum for a contract to deploy new contracts. Effectively, in Ethereum, smart contracts are no less powerful than human agents.

https://dappsforbeginners.wordpress.com/tutorials/interactions-between-contracts/
https://zupzup.org/smart-contract-interaction/
https://ethereum.stackexchange.com/questions/44383/creating-a-function-that-calls-another-contract

[Lebowski1234]

Can I please make a feature request for two functions to be added to the Golang code:

1. In walletapi package: function for signing a hash (e.g. Keccak256) with an account and returning the signature.

2. Function that takes a hash and signature as inputs, and returns the account address that was used to produce the signature.

The usage of these two functions would be proving that a given address has signed the hash of a string. To be clear, these functions are not DVM functions, but are Golang library functions for other software that imports dero. They would be used off-chain.

[Cryptomancien]

• official group in stackoverflow
• function to import - export data from another file
• boolean type

[derotester]

FUNCTIONS TO ADD:

Uint64 SC_DERO_BALANCE(): return dero balance in SC wallet

Uint64 SC_TOKEN_BALANCE(): return token balance in SC wallet

SEND_TOKEN_TO_ADDRESS(a String, amount Uint64): send token deposited in SC wallet

BURN_SC_TOKEN or BURN_VALUE(amount Uint64): burn token deposited in SC wallet

similar to send_token_to_address a registred tx that prove the burn

BURN_SC_DERO or BURN_DERO(amount Uint64): burn token deposited in SC wallet

similar to send_token_to_address a registred tx that prove the burn

[LadTy]

What was already mentioned but I would find really useful:

• invoke other SCs
• arrays
• string operations (strlen, substr)
• real-world date and time functionality and operations (unix timestamp is fine)
• hash functions

Additional (very important to me):

• the ability for a SC to access (read) current and past TXs by TXID it was involved in, particularly encrypted data (as text) present in it