What are dApps?

A distributed application (dApp) is an application whose backend runs on a decentralized peer-to-peer network and maintains its source code as open source. The data for the dApp is replicated among all nodes to achieve both consensus of state and a consistent data availability. As an example, Bitcoin itself would be considered a dApp which employs the “blockchain” data structure. dApps allow for dependable application uptime without the need of centralized servers that can suffer “single point of failure” issues.

The nature of distributed applications encourages a higher standard of both client privacy and prevents the suppression and censorship of information by private or governmental entities. Using the Ethereum Virtual Machine (EVM) model, the PUFFScoin development group will build, maintain and update dApps that will permit a freer economy based upon the cannabis regulatory atmosphere.

Every action recorded on the PUFFScoin blockchain is triggered by transactions fired from user accounts (EOAs). By default, the PUFFScoin execution environment is lifeless; nothing happens and the state of every account remains the same. Each time a contract account receives a transaction, its code is executed as instructed by the input parameters sent as part of the transaction. This is performed by the EVM on each PUFFScoin node participating in network consensus through the verification of new blocks.

This execution needs to be absolutely conclusive and deterministic, the context of the operation is to record the change in state in a smart contract. “Contracts”, as defined for the EVM are not something that should be “fulfilled” or “complied with”; such as a mortgage, or business partnership. These use-cases CAN be satisfied by encoding a smart contract to maintain the variables needed. Instead, smart contracts on PUFFScoin they are similar to “autonomous agents” that live inside of the PUFFScoin computational execution environment.

These contracts will execute a specific piece of code when called by a message or transaction and will be available at their contract address unless the contract owner evokes a suicide function on the contract. The code may read/write to its own internal storage (a database mapping 32-byte keys to 32-byte values), read the storage of the received message, and send messages to other contracts, triggering their execution in turn. Once code execution stops, and all sub-executions triggered by a message sent by a contract stop, in a synchronous order, the execution environment halts once again, until woken by the next transaction.

The term “transaction”, in reference to PUFFScoin blockchain operation refers to the signed data package that stores a message to be sent from a user account to another account on the blockchain.

Transactions contain:

-the recipient of the message,
-a signature identifying the sender
-a VALUE field which represents the amount, in wei (1 PUFFS = 1e18 wei), to transfer from the sender address to the recipient’s address,
-an optional data field, which can contain the message sent to a contract,
-a STARTGAS value, representing the maximum number of computational steps the transaction execution is allowed to take,
-a GASPRICE value, representing the fee the sender is willing to pay for gas.

A message contains the much of the same information that is included in a transaction, excepting that a message is produced by a contract as it executes codes such as CALL and DELEGATECALL. In this manner, contracts can communicate with other contracts in exactly the same way that external end-users can.

Contracts generally serve four purposes:

-Maintain a data-store representing something which is useful to either other contracts or to the outside world; (ie: a sub-currency, membership records for a DAO)
-Serve as a sort of user account with a more complicated access policy, what is called a “forwarding contract” and typically involves simply resending incoming messages to some desired destination only if certain conditions are met (ie: a forwarding contract that waits until two of three private keys have confirmed a message before continuing to forward it on)
-Manage an ongoing contract between multiple users. (ie: financial contracts, escrow services with trusted mediation, insurance)
-Provide functions to other contracts, essentially serving as a software library.

Contracts are written in a high-level computer language, such as Solidity, and then compiled into bytecode to be uploaded on the blockchain. Contracts live on the blockchain as an EVM-specific binary format (EVM bytecode) that is executed by the Ethereum Virtual Machine (EVM). However, contracts are typically written in a higher level language and then compiled using the EVM compiler into bytecode to be deployed to the blockchain.

[Solidity] is a programming language similar to JavaScript, and is the most common language used in contract development. [Serpent] is based on Python and is also used for contract development and to compile the resultant code into EVM-bytecode. [LLL] or Lisp Like Language is a low-level language similar to Assembly used to wrap over coding in the EVM directly.

Compiling contracts may be accomplished through a number of tools. At the most basic level, users can set up the solc compiler in gpuffs and is installed with the cpp-puffscoin client. Using the JavaScript console in the gpuffs client, users can apply


Online, users of PUFFScoin can utilize the services provided by , an online solidity compiler. More advanced users can build a local copy of the MeteorJS development environment Cosmo on their computers to compile locally . Finally, users can leverage the in-wallet compiler and contract interaction forms via our GUI wallet HÄZ.

Once compiled, smart contract code is presented as EVM-bytecode, which is uploaded by various means onto the blockchain. Interacting with a contract will require the contract wallet address and the [abiDefinition] to be provided by the contract owner, although to interface with many ERC20 tokens require a user to simply follow the token contract address.

Interaction with a contract is generally accomplished using the eth.contract() function which returns a javascript object with all of the contract functions available as callable functions in javascript. The ABI definition is an array which describes the functions of the contract as call signatures and return values for each available function. The function calls specified in the ABI are made available on the contract instance, and can be called by a simple CALL function or through a sendTransaction operation.

When called using sendTransaction, the function call is executed by broadcasting a transaction. This will cost PUFFS in the form of gas to send and the call will be recorded in the blockchain. When called using CALL, the function is executed locally in the EVM and the return value of the function is returned with the function. Calls made in this manner are not recorded on the blockchain and thus, cannot modify the internal state of the contract. This manner of call is referred to as a constant function call, and do not cost any gas.

Contracts which are deployed by the PUFFScoin Core Development team will endeavor to ensure that the contract metadata such as documentation and source code is made available by registering this information on the blockchain. The intrinsic ‘admin’ API built into the PUFFScoin network provides a convenient way for users to fetch this information through the admin.getContractInfo command, and we will have this data published in our PUFFScoin block explorer where we have the ability to do so.

When a contract is executed on the blockchain, as a result of being triggered by a message or transaction, each parameter of the contract call is executed on every node of the PUFFScoin network. For each operation execution, there is a specified cost, expressed in a number of gas units. Gas and puffs are deliberately separate entities: units of gas represent units of computation power, while the price of PUFFScoin fluctuates as a result of market forces. The two are mediated using free-market ideals: the price of gas is essentially decided by the miners, who can refuse to process a transaction offering a lower gas price than the minimum limit they set.

Although miners do not receive the gas generated through transactions and computational costs, they are sent through to the Veterans Endowment, we hope that miners participate with our philanthropic ideals, and will help in providing value to the Veterans Endowment by requiring users to maintain an equitable cost for computation in gas.