Starting with SmartPy Part 6: Creating a dApp

Using ConseilJS to bring smart contracts to the web

What makes a dApp different from other kinds of software is that some critical component of the business logic resides in a smart contract on a blockchain. The previous sections covered blockchain interaction and smart contract composition. Creating an interactive UI will finally let users take advantage of blockchain-based functionality without the complexity usually associated with that. This article will cover development a simple web page, but it is absolutely possible to build dApps for any target, consider TezosKit for iOS and macOS; PyTezos & ConseilPy for python, TezosJ for Android and more.

Functionally the dApp will do several things:

• Present a UI to collect user input for contract interaction.
• Sign contract interaction operations.
• Provide feedback about the results of the operation.

For simplicity we’ll use the addition contract from Part 1. The full HTML page and JavaScript code is available on [GitHub](https://gist.github.com/anonymoussprocket/bff45e30a24d956c033629f0c8f553f5), below we’ll just cover some of the interesting parts.

ConseilJS is available as an NPM package for nodejs-based deployments, including electron and also as a minified webpack’ed file for direct HTML development. It can be included as follows. It’s encouraged to provide the integrity hash, it is available on the main GitHub page.

<script src="https://cdn.jsdelivr.net/gh/cryptonomic/conseiljs/dist-web/conseiljs.min.js"></script>

The application needs to sign transactions submitted by some account, this account is funding the execution of said transactions. For this reason the application needs access to the private key. It should be noted that this application is just a demonstration. Production deployments must take great care to secure the user’s private key. ConseilJS offers several means of signing the operations, in this case we’re using the integrated signer, therefore we provide the key. This key can also be collected from the user as a parameter, it may in the future come from a browser extension-based signer, etc. TezosWalletUtil.restoreIdentityWithSecretKey() provides a quick way of generating the necessary object.

The invokeContract() function in the dApp collects user input and invokes the contract with the provided parameters. In a production setting it would need to validate this input. The app should also be transparent about the fees required to record this transaction on the chain. We’re also hard-wiring the destination contract as KT1C8eB3d2VQnuj6ARRT8V4jRUhUuYeNcQK1, this was deployed on babylonnet prior to writing using the instructions in Part 4. We encode the user input into appropriate format and then submit the transaction with sendContractInvocationOperation(). At this stage, assuming a successful submission, the operation is populated into the blockchain mempool from which a Tezos baker will pull operations for inclusion in a block. As such we might want to wait for the operation to be actually executed and recorded. This is accomplished with awaitOperationConfirmation.

The object coming out of this function call contains a plethora of useful information, including actual amount of consumed_gas, and the updated storage . If the operation was rejected for some reason, the details of that would be available in the block (block_hash) where it was processed.

With this we’ve closed the loop, starting with smart contract composition with SmartPy, contract deployment & interactions with ConseilJS, blockchain infrastructure with Nautilus Cloud, and finally this simple UI users on the internet can take advantage of the contracts via a browser. This is certainly just the beginning and many topics, among them, key security, contract security, complex contract parameters and entry-point-based invocation, were not covered in detail. We hope this was an informative introduction and we hope you stick to blockchain development with us.