Developing a Dapp on Tezos
This article presents a simple Dapp developed as a POC for the blockchain workgroup at Cap digital (the main French business cluster).
It illustrates a basic architecture of a Dapp on Tezos and may serve as a starting/study point for any new developer in the Tezos community.
The Dapp is available online and the smart contract is deployed on Babylon net. The source code is available here.
The Dapp uses the following tools and libraries:
- Archetype language to develop the smart contract
- Tezbridge as the wallet
- Taquito to interact with the smart contract
More information is provided in the “Implementation” section below.
This work is sponsored by the Tezos foundation as part of the Archetype project.
Follow the Archetype project on twitter:
Certification token
One of the questions addressed by the workgroup is the use of blockchain (BC) technology for education. The use of BC to record diplomas on-chain is already well addressed by several companies. Recent French educational policies have focused on the use of technology for Lifelong Learning (competency databases, analytics, …).
This Dapp proposes a “token” linked to lifelong learning effort: a learner gains tokens when passing professional certifications. The number of accumulated tokens acts as a metric of the learning effort and the Dapp’s smart contract acts as a public cross-institution certification database.
In order to compute the number of tokens, the Dapp’s smart contract registers learners’ certifications. A certification is comprised of the following data:
- certificate id
- learner id
- institution id
- certifier id
- date
Tezos account identification serves as the identifier used in the Dapp.
The learner’s institution is the university or the company the learner respectively studies in or works for. The distinction between institution and certifier covers the situation of an employee who is required by his company (the institution) to pass a professional certification. The company that provides the certification is the certifier. When a student gets a diploma delivered by the university she or he studies in, the university is both the institution and the certifier.
When a certification is registered, the corresponding tokens are granted to the learner and the institution. The institution tokens is a metric for institution effort to send its learners for certifications.
Interactions
The Dapp enables to login as Learner, Institution or Certifier. A Tezos account identifier is used as the Dapp identifier.
A Tezos account is selected (here with Tezbridge):
When not yet registered, click the “register” button:
A learner may view the number of tokens and the list of her/his certifications:
An institution may view its number of tokens and register its learners:
A certifier registers certifications:
The database of certificates used in this demo is the open Onisep database of the initial training certificates in France. The certifier selects a certificate from this database:
Implementation
Smart contract
The smart contract is developed in Archetype, a high-level domain-specific language to develop smart contracts on Tezos. Archetype transcodes to other languages:
- Ligo or Scaml for execution (compiled to Michelson)
- Why3 for formal verification
- Markdown for documentation
The smart contract source code is available here. The version of Archetype used in the examples below is 0.1.12.
The contract storage is modeled with 4 assets: learner, institution, certifier, and certification:
The contract provides 5 entries:
- register_learner, register_institution, and register_certifier to register the caller as one of the corresponding roles
- register_learners for an institution to associate learners (eg. a university registers students and a company registers employees)
- certify for a certifier to register certifications
The certify entry point receives the certification assets (line 18 above) to register:
There is one main principle when designing a Dapp and the associated smart contract:
Data calculations should be performed off-chain and the smart contract should limit itself to checking the consistency of the input data.
This principle is illustrated in the certify entry point: while the contract possesses the information of which learners are associated to an institution (via the ilearners field of the institution asset line 11 above), the certification data passed as argument comes with the institution id the learner is associated with.
The smart contract could potentially retrieve the institution id but that would require extra calculations that are not worth spending in gas. This is computed off-chain by the Dapp, from the contract storage data.
The smart contract just checks whether the association provided is consistent with what it knows (lines 8 and 9 below):
In this Dapp, the Michelson has been generated via the Ligo language. The deployment procedure of the Archetype contract is described in this document. It consists in:
- generating the Ligo from Archetype
- compiling the Ligo to Michelson
- deploying the contract (on Babylon net)
Tezbridge
Tezbridge is currently used to select the Tezos account and forge transactions.
3 accounts (1 learner, 1 institution, and 1 certifier) are available for you to register in your wallet to interact with the Dapp.
Follow this procedure to add these accounts to the Tezbridge wallet.
Taquito
Taquito is a powerful library to retrieve contract storage and forge transactions in a high-level seamless way. Indeed it provides a reified view of the smart contract such that you can interact with it through a plain object interface.
For example, the following snippet (from the UI component Login.js) retrieves the number of tokens of learner tezid :
The storage object provides the members that correspond to the contract storage fields (like institution_assets line 11 above).
Note that Michelson annotations of storage type and entry points are used to build this plain object version of the contract. The benefit of using high-level languages is the automatic annotations of the generated Michelson.
What’s next?
Some key features are still missing for this Dapp to be really used.
Whitelisting of certifiers
The main issue is that anyone can record new certifications: there should rather be a whitelisting process when registering as a certifier.
This process should implement a basic voting algorithm among a set of voter accounts. The Dapp should provide voter accounts with notifications when a request for registration is emitted. This voting process should be backed up by a smart contract to keep a trace in case of an inquiry.
The same process could be applied to register institutions.
Learner id
The question is still open to know whether the use of Tezos account id is consistent with data privacy constraints imposed by EU (see GDPR).
…
Follow the Archetype project on twitter: