On Waves, just like on many chains, interactive apps (games, social, automation) quickly hit a wall:

• users have to confirm a wallet popup constantly
• users pay fees for every action
• onboarding becomes painful

This article introduces Waves DA (Dapp Abstraction) — a smart-contract pattern built with Waves primitives (dApps + data storage) that dramatically reduces user signatures while keeping users in control.

This is a composable pattern: smart account + registry + relayer.

1) Core concept: separate ownership from execution

Waves DA introduces one idea:

Users own the account. Relayers execute actions. The blockchain sees the user’s account as the caller.

Instead of calling dApps directly from an EOA (eg: Keeper etc), the user calls through a DA Wallet:

• a DA Account is a proxy dApp
• deployed per user
• controlled by the user (owner stored on-chain)
• can authorize one or more relayers to call target dApps and methods through a generic proxy

So when a relayer executes something, the target dApp sees the DA Wallet as caller, not the backend or relayer.

        (User-controlled)                             (Project-controlled)
┌───────────────────────────────┐               ┌────────────────────────────┐
│  EOA Wallet (Keeper / Signer) │               │      Relayer Backend       │
│  - signs init & permission txs│               │  - can sponsors fees           │
│  - never shares DA seed       │               │  - never owns user account │
└───────────────┬───────────────┘               └────────────┬───────────────┘
                │                                            │
                │ (EOA invokes)                              │ (Relayer invokes)
                v                                            v
      ┌───────────────────┐                     ┌─────────────────────────┐
      │ DA Wallet (dApp)  │<--------------------│  Global Registry (dApp) │
      │ - proxy + perms   │    resolve EOA→DA   │  activeDA_<EOA> = <DA>  │
      │ - owner stored    │-------------------->│  single source of truth │
      └─────────┬─────────┘                     └─────────────────────────┘
                │
                │ (DA invokes target dApps)
                v
       ┌──────────────────┐
       │   Target dApps   │
       │   caller == DA   │
       └──────────────────┘

2) The three building blocks

A) The DA Wallet (proxy smart contract/ dApp)

This is deployed on the user’s DA address and provides:

• proxy()a generic “forward call to any dApp” entrypoint
• permission system scoped by:
  - relayer + dApp + method (with optional expiry)
  - or relayer + dApp (allow all methods on that dApp)
• payment caps per relayer + dApp + method, including per-asset caps
• pause / unpause (owner-only)
• emergency withdraw (owner-only)
• optional fee reimbursement to the relayer (requested per call, enforced by the DA script and backend policy)

B) The global registry (single dApp)

A single registry stores the canonical mapping:

activeDA_<EOA_ADDRESS> => <DA_ADDRESS>

This matters because:

• backends must never trust a DA address coming from the frontend
• the registry becomes the source of truth for all relayers and apps
• The registry verifies the EOA→DA link using i.originCaller and the DA’s pendingOwner stored on-chain.

C) Relayers (backends)

Relayers:

• read EOA→DA mapping from the registry
• build & broadcast proxy() calls on DA
• sponsor fees or;
• receive fee refunds from the DA

The backend also includes a safety check (refundGuard) to validate (via node validation) that the DA will refund the expected fee before broadcasting if needed.

3) The most important security detail: preventing init frontrun

The DA Wallet is generic: it should not have a hardcoded owner address in the script.

So ownership is stored in data storage (e.g. owner = "<EOA>"), and initialization sets it.

But there’s a well-known risk:

After setScript, the account becomes invocable by anyone.
If initialization simply sets owner = i.caller, a third party could invoke first and become owner.

That’s a classic “first-in wins” initialization frontrun scenario.

The solution: pendingOwner written before setScript

The deployment flow solves this by writing a Data Transaction before deploying the script:

1. Generate DA seed locally (frontend only)
2. Fund the DA
3. Write on the DA Wallet data storage:

pendingOwner = "<EOA address>"

(signed by the DA seed, since the DA account doesn’t exist as a dApp yet)

4. Deploy the proxy script (setScript, signed by DA seed)

Now, even if someone tries to frontrun an init call, the script requires:

• i.caller == pendingOwner

So only the intended EOA can initialize.

This keeps the proxy script generic (no hardcoded EOA), while still safe.

4) One-click setup: Init + Register in a single EOA transaction

Once the proxy script is deployed, the user does one single EOA-signed transaction:

EOA → invoke DA.initAndRegister(registryDapp)

This callable does two things atomically:

1. initialize DA (set owner, set initialized, delete pendingOwner)
2. register in the global registry via dApp → dApp call

Example of the initAndRegister() call:

@Callable(i)
func initAndRegister(registryDapp: String) = {
  # Read pendingOwner and bind ownership to the EOA caller
  let eoaStr = toBase58String(i.caller.bytes)
  let p = match getString(this, "pendingOwner") {
      case s:String => s
      case _        => throw("pendingOwner missing")
    }
    if (p != eoaStr) then throw("Only pendingOwner can init") else {
      let reg = Address(fromBase58String(registryDapp))
      # Register EOA > DA on global registry
      strict regCall = invoke(reg, "registerFromDA", [], [])
      [
        StringEntry("owner", eoaStr),
        BooleanEntry("initialized", true),
        DeleteEntry("pendingOwner")
      ]
    }
}

Result: one tx initializes and links the DA.

5) How the registry safely links EOA → DA (without trusting frontend)

The registry callable used by this flow is registerFromDA().

It receives:

• the originating EOA as i.originCaller
• the DA as i.caller

The registry does not trust originCaller alone; it also checks the DA’s on-chain pendingOwner.

@Callable(i)
func registerFromDA() = {
  let eoaStr = toBase58String(i.originCaller.bytes)
  let da     = i.caller
  let existing = match getString(this, "activeDA_" + eoaStr) {
      case s:String => s
      case _        => ""
    }
    if (existing != "") then throw("DA already linked") else {
      let p = match getString(da, "pendingOwner") {
        case s:String => s
        case _        => throw("DA pendingOwner missing")
      }
      if (p != eoaStr) then throw("DA pendingOwner mismatch")
      else [
        StringEntry("activeDA_" + eoaStr, toBase58String(da.bytes))
      ]
    }
}

This is the key:
✅ registry is global and canonical
✅ relayers can trust it
✅ linking is on-chain verified (not frontend claims)

6) Calling target dApps through the proxy (without user signatures each time)

After initialization + registration, the user can authorize a relayer:

• approveMethod(relayer, dapp, fn, expireHeight)
• or allowAllOnDapp(relayer, dapp, expireHeight)
• and set payment limits per call / asset

Permissions are set by the DA owner (EOA) via owner-only callables.

Then the relayer can execute:

Relayer → invoke DA.proxy(...)

The DA:

• checks permissions and limits
• forwards the call to the target dApp using invoke(target, fn, args, payments)
• optionally refunds fees to the relayer (if required)

Here a simplified proxy outline:

@Callable(i)
func proxy(target: String, fn: String, args: List[Int], reimburse: Boolean) = {
  if (!match getBoolean(this, "initialized") { case b:Boolean => b case _ => false }) then
    throw("Not initialized")
  else {
    # permission checks omitted for simplification
    let targetAddr = Address(fromBase58String(target))

    # args decoding omitted for simplification
    strict call = invoke(targetAddr, fn, decodeArgs(args), [])
    # Optional fee refund (exact fee amount + asset id)
    if (reimburse) then
      [ ScriptTransfer(i.caller, i.fee, i.feeAssetId) ]
    else
      []
  }
}

The “caller identity” property (critical)

In the example target dApp below:

{-# STDLIB_VERSION 6 #-}
{-# SCRIPT_TYPE ACCOUNT #-}
{-# CONTENT_TYPE DAPP #-}

func callerStr(i: Invocation) = toBase58String(i.caller.bytes)

@Callable(i)
func YYY3(a: Int, s: String, b: Boolean) = [
  StringEntry("YYY3_caller", callerStr(i)),
  IntegerEntry("YYY3_a", a),
  StringEntry("YYY3_s", s),
  BooleanEntry("YYY3_b", b)
]

It store:

• caller = i.caller

When the relayer calls through DA proxy:

• the target dApp sees i.caller = DA, not the relayer.

That’s exactly what makes this pattern powerful:
the DA Wallet is the on-chain actor.

Permissions are managed by the DA owner (EOA) via owner-only callables like approveMethod / allowAllOnDapp.

7) Relayer safety: refund guard

A practical problem: relayers don’t want to sponsor calls if refunds are misconfigured or revoked.

The backend includes a refundGuard step:

• validates (via node simulation/validate) that the call will include the expected refund transfer to the relayer
• only broadcasts if the refund is guaranteed by script execution

This makes fee sponsorship robust and predictable.

Optional hardening: registry could store proxyVersion/scriptHash to ensure DA runs expected code, hence why we do not want store any address in the code.

8) Threat model

This pattern doesn’t pretend seeds are magic.

• If the DA seed is compromised during setup, that’s critical (like any wallet).
• The goal is: backends are never owners, and delegation stays revocable.

Strong properties:

• relayers are scoped and revocable (no global allow-all relayer)
• registry is the source of truth (no frontend spoofing)
• init cannot be frontrun due to pendingOwner
• permissions are per relayer + dApp (+ method) with optional expiry
• emergency pause + withdraw exists

9) Why this matters for Waves

Waves DA enables “AA-like” UX patterns on Waves:

• Sponsored interactions if project/ relayer want to.
• game loops and micro-actions without constant signing
• backend automation with clear, revocable permissions
• target dApps seeing DA identity as caller (not backend identity)

All without protocol changes.

Closing

Dapp Abstraction is not a theoretical pitch.
It’s a working end-to-end PoC using Waves-native primitives:

• DA Wallet proxy smart account
• registry mapping EOA→DA
• safe init (pendingOwner written before setScript)
• one-click init + register
• relayer execution through proxy with optional refunds

If you’re building interactive apps on Waves, this pattern can significantly improve UX while keeping user control intact.

NFTs on the Waves blockchain currently suffer from a lack of a standard, preventing the unification of all NFTs across different platforms and tools supporting Non-Fungible Tokens.

At the moment, projects like SIGN Art, Puzzle Market, Waves Keeper, etc., if they want to support new NFT collections issued outside of their platform/dApp, have to write wrapper code for each one, making it a tedious and non-scalable task.

WHY IS IT THAT WAY?

Let’s keep it short, but basically, it is mostly due to the very cheap cost on Waves to store data on-chain. Therefore, all projects issuing NFTs decided to store data directly on-chain with their own “standard” key/value, which is different for each project.

Let’s take the example of SIGN Art; adding a new NFT will create a set of data entries on-chain, such as:

"art_maxmint_Hv7muNhZnCLD47J9tYkURiLwmq1MKyitAidBtmk8RJhB_3NB22KNd6CsjzLyWRQxKg2CVnLfWZRD3pNX": 100
"art_price_Hv7muNhZnCLD47J9tYkURiLwmq1MKyitAidBtmk8RJhB_3NB22KNd6CsjzLyWRQxKg2CVnLfWZRD3pNX": 150000000
"art_royalties_Hv7muNhZnCLD47J9tYkURiLwmq1MKyitAidBtmk8RJhB_3NB22KNd6CsjzLyWRQxKg2CVnLfWZRD3pNX": 400
"art_licence_cid_Hv7muNhZnCLD47J9tYkURiLwmq1MKyitAidBtmk8RJhB_3NB22KNd6CsjzLyWRQxKg2CVnLfWZRD3pNX": "bafybeifuyo4pqu54ismqgtb6e4h6kkvgx7zg4u3zibh2r7y6mb64i7bzza/licence.pdf"
"art_licence_hash_Hv7muNhZnCLD47J9tYkURiLwmq1MKyitAidBtmk8RJhB_3NB22KNd6CsjzLyWRQxKg2CVnLfWZRD3pNX": "a87758c354e30a9e78fb84fa3a0010a5090ab20df0be11ad45b5720cc187e639"
"art_export_hash_Hv7muNhZnCLD47J9tYkURiLwmq1MKyitAidBtmk8RJhB_3NB22KNd6CsjzLyWRQxKg2CVnLfWZRD3pNX": "6bc24b3e7e8cb14ddb0045b4b9fa1794c0bd77aff45b45ec06ec30de7e8d399f"
"art_export_cid_Hv7muNhZnCLD47J9tYkURiLwmq1MKyitAidBtmk8RJhB_3NB22KNd6CsjzLyWRQxKg2CVnLfWZRD3pNX": "bafybeihx75xsirilentjh4gzcwgqrfrm3l3m2boflp5wtae5mefks5p5wq/exported.png"
"art_display_cid_Hv7muNhZnCLD47J9tYkURiLwmq1MKyitAidBtmk8RJhB_3NB22KNd6CsjzLyWRQxKg2CVnLfWZRD3pNX": "bafybeihbkmsqhenkuongrckkpcnmqr45m4ljs54swptjpo2ofzdhudisaq/display.png"
"art_desc_Hv7muNhZnCLD47J9tYkURiLwmq1MKyitAidBtmk8RJhB_3NB22KNd6CsjzLyWRQxKg2CVnLfWZRD3pNX": "test"
"art_name_Hv7muNhZnCLD47J9tYkURiLwmq1MKyitAidBtmk8RJhB_3NB22KNd6CsjzLyWRQxKg2CVnLfWZRD3pNX": "Hydden"
"art_date_Hv7muNhZnCLD47J9tYkURiLwmq1MKyitAidBtmk8RJhB_3NB22KNd6CsjzLyWRQxKg2CVnLfWZRD3pNX": 1696994137141
etc…

On the other hand, Puzzle Market will create a different set:

"nft_8yPbzhadExk2HnwsuSHeXPydqY49qmA4Y9Zp7HkNDoCM_issuer": "3PKVgd6ds1xervK6bPXbEHBqg8ibTcf5HZk"
"nft_8yPbzhadExk2HnwsuSHeXPydqY49qmA4Y9Zp7HkNDoCM_image": "https://ipfs.io/ipfs/QmTJsdn6ETpdHDyP2SbR49uciqpy9fq5sn27WPWoiM9kC6"
"nft_8yPbzhadExk2HnwsuSHeXPydqY49qmA4Y9Zp7HkNDoCM_data": "{'collection': '3PKVgd6ds1xervK6bPXbEHBqg8ibTcf5HZk_ania', 'num': 3}"
"nft_Gnpy5nVajPP3XQQVxrHboMAsXtjnyWAxybMDdKrbr8sD_original": "https://ipfs.io/ipfs/bafybeifiikpgay7dayc2spiite27fcpvpcnlxmwefnnskg35zmrvk2d54q/original.png"
etc…

The same applies to any other NFT project on Waves. To change this, we need to follow the most-used standard that all other networks follow, from all EVM Chains to Solana and more. The standard is the following:

All data is stored in a JSON file on IPFS, while only the hash (called a CID on IPFS) to access this JSON is stored on-chain. This standard makes sense, as NFTs started on Ethereum, and storing a lot of data on-chain with the high gas cost it implies was not a good idea.

All media are also stored on IPFS, and their CIDs are included in the JSON. Here’s a simple example of such JSON:

{
  "name": "Name of NFT",
  "description": "Description of NFT",
  "external_url": "https://marketplace.io/id_of_the_nft",
  "image": "ipfs://CID_GOES_HERE",
  "attributes": [{}]
}

There is basically a set of predefined properties recognized by most platforms:

name:
Name of the item.

description:
A human-readable description of the item.

image:
This is the URL to the preview/ display image of the item. Can be just about any type of image, stored on IPFS starting with ipfs:// (recommended) or HTTPS paths starting with https://.

external_url:
This is the URL that will allow the displaying platform to send the visitor to the origin platform, for example if the NFT is sold on Puzzle Market and was issued on SIGN Art, this is the link to the initial NFT drop on SIGN Art.

animation_url:
This is the URL to a multi-media attachment for the item. This file extension could be anything from MP4 to GLB or MP3 but not all platform will support all extensions.

animation_type:
This is the file format of the multi-media attachment provided from animation_url, this allow to quickly identify the media type.

attributes:
These are all the custom attributes for the item

Any other needed data is generally added as “attributes/traits”:

  "attributes": [
    {
      "trait_type": "Base", 
      "value": "Starfish"
    }, 
    {
      "trait_type": "Eyes", 
      "value": "Big"
    }, 
    {
      "trait_type": "Mouth", 
      "value": "Surprised"
    }, 
    {
      "trait_type": "Level", 
      "value": 5
    },
    {
      "display_type": "boost_number", 
      "trait_type": "Aqua Power", 
      "value": 40
    }, 
    {
      "display_type": "boost_percentage", 
      "trait_type": "Stamina Increase", 
      "value": 10
    }, 
  ]

HOW DO WE MOVE TO A SIMILAR STANDARD?

With the upcoming launch of SIGN Art V2, which comes with a lot of changes, including the removal of the “curated only” access and the support of NFTs issued on any other platform (complying with the standard) to be sold in our secondary market, such a standard is required.

It will be up to each project to align with such a standard or not, but we propose a way to do the transition that will allow anyone to follow the standard, even old existing projects, while not having to drop what they implemented already, as both can coexist on-chain. Also, with the upcoming WAVES 2.0 using EVM and a good number of EVM projects potentially moving to Waves, this is even more important to start having a standard.

Of course, SIGN Art will also comply with this standard, and it will be done as follows:

To easily retrieve the CID leading to the JSON containing the data of any given NFT, we will simply query the data storage of the issuer account looking for a data entry with a key using the following structure:

`std_nft_${nft_id}_metadata`

If this returns a CID, then we can request the associated JSON on IPFS.

// Here an example how you could validate that the json have your platform requirement properties
const isValidMetadata = function(metadata){
  let is_valid = false
  if(Object.hasOwn(metadata, 'name') && Object.hasOwn(metadata, 'description') && Object.hasOwn(metadata, 'image') && Object.hasOwn(metadata, 'external_url')){
    is_valid = true
  }
  return is_valid
}

// Here an example how to retrieve the NFT metadata on IPFS base on the NFT ID and ISSUER address
const get_nft_metadata = async function(nft_id, issuer){
  let data_entry_regex = `std_nft_${nft_id}_metadata`
  let metadata = null
  let nft_is_valid = false
  let nft_is_valid_msg = ""
  try{
    let get_link = await fetch(nodeURL+"/addresses/data/"+issuer+"?key="+data_entry_regex)
    let get_link_json = await get_link.json()
    if(get_link_json.length){
      const get_json_from_ipfs = await fetch("https://cloudflare-ipfs.com/ipfs/"+get_link_json[0].value)
      const result_json = await get_json_from_ipfs.json()
      if(isValidMetadata(result_json)){
        metadata = result_json
        nft_is_valid = true
      }else{
        nft_is_valid_msg="This NFT metadata don't follow the required standards"
      }
    }else{
      nft_is_valid_msg="This NFT don't follow the required metadata standards"
    }
  }catch(err){
    console.log(err)
  }
  if(!nft_is_valid){
    console.log("nft_is_valid_msg", nft_is_valid_msg)
  }else{
    console.log("metadata", metadata)
  }
}

get_nft_metadata("CnrsX8Gdsr2LFWTbeWd52KrJFhtHTuxtzEpkWpguZ1aC", "3N9o4fNhKnVigxGjWv4MuiGXwK94SiQhomm")

You can find the data entry of the NFT from this example on the issuer testnet address:

w8 · 3N9o4f···homm

And the JSON on IPFS from the returned CID:
https://cloudflare-ipfs.com/ipfs/bafkreiaoncqchjss5yjizg2eljm5q66suprnud535jplfaoeofcvkjijpq

On the issuer side, generally the project dapp, the only requirement is to add the new STD entry when creating new NFTs.

For their existing NFTs/Entries, they can run a script that will retrieve the data from their dapp storage for each issued NFT and then do two things:

1. Structure a JSON following the standard and add it to IPFS (remember to pin the file to ensure that they are not removed later by the garbage collector.)
2. From the CID received from adding the JSON to IPFS, add a new data entry on the dapp storage with “std_nft_{nft_id}_metadata” as the key and the CID as the value:

"std_nft_CnrsX8Gdsr2LFWTbeWd52KrJFhtHTuxtzEpkWpguZ1aC_metadata": "bafkreiaoncqchjss5yjizg2eljm5q66suprnud535jplfaoeofcvkjijpq",

Here’s another example of a JavaScript code getting all the issued NFT data from a given issuer/dapp, generating each JSON, adding them to IPFS, and then adding the std entries to the issuer dapp with the CIDs as values:

const encodeUrl = require('encodeurl');
const ipfs = require("./ipfs")
const {data, broadcast} = require('@waves/waves-transactions')

require("dotenv").config();

const node_url = process.env.node_url
const dapp_seed =process.env.dapp_seed
const chain_id = process.env.chain_id

const key_image = "displayCid_"
const key_title = "name_"
const key_description = "desc_"

const get_nft_data_from_event = async function(issuer, key){
  let obj = {
    name: "",
    description: "",
    image: "",
    external_url: "",
    attributes: [
     /*  {
        "trait_type":"Rarity Class",
        "value":"Normal"
     } */
    ],
    //animation_url: "https://signart.infura-ipfs.io/ipfs/bafybeibkgflciimyuwlmgffeiqriokoebfa7upurn2lpmdfxv7facfkm3u/exported.mp4",
    //animation_type: "MP4"
  }
  let regex = encodeUrl(`${key_title}${key}|${key_description}${key}|${key_image}${key}`)
  try{
    let get_link = await fetch(node_url+"/addresses/data/"+issuer+"?matches="+regex)
    let get_link_json = await get_link.json()
    
    for(const i of get_link_json){
      if(i.key.includes("name")){
        obj.name = i.value
      }
      if(i.key.includes("desc")){
        obj.description = i.value
      }
      if(i.key.includes("displayCid")){
        obj.image = "ipfs://"+i.value
      }
    }
  }catch(err){
    console.log(err)
  }

  return obj
}

const add_to_ipfs = async function(json) {
  try{
    const add = await ipfs.upload(json)
    return add
  }catch(err){
    console.log(err)
    return err
  }
}

const add_meta_entry_to_dapp = async function(key, cid){
  const signDataEntry = await data(
    {
      data: [
          { key: key, value: cid }
      ],
      fee: 500000,
      chainId: chain_id
    }, 
    dapp_seed
  )

  try{
    const broadcast_entry = await broadcast(signDataEntry, node_url)
    console.log(broadcast_entry)
    return {error: false, result: broadcast_entry}
  }catch(err){
    console.log(err)
    return {error: true, result: err}
  }
}

// retrieve all NFT data on the issuer dapp
const get_event_id_from_nft_id = async function(issuer){
    // here we query the name_(.*) keys for each issued NFT to get each NFT ID that is included in this key
    const regex_key_on_dapp = `name_(.*)`
    try{
      const get_link = await fetch(node_url+"/addresses/data/"+issuer+"?matches="+regex_key_on_dapp)
      const get_link_json = await get_link.json()
      for(const i of get_link_json){
        // we split the key ex: "name_CnrsX8Gdsr2LFWTbeWd52KrJFhtHTuxtzEpkWpguZ1aC" to get the NFT ID
        const data = i.key.split("_")
        const nft_id = data[1]
        
        try{
          // check if NFT metadata standard exist already on issuer dapp
          const regex_key_meta_on_dapp = `std_nft_${nft_id}_metadata`  
          const have_metadata = await fetch(node_url+"/addresses/data/"+issuer+"?matches="+regex_key_meta_on_dapp)
          const have_metadata_json = await have_metadata.json()
          // if not, get the data from issuer dapp storage
          if(!have_metadata_json.length){
            // once we get the event key, we query the event data
            const res = await get_nft_data_from_event(issuer, nft_id)
            res.external_url = "https://anything.org/"+data[1]
            const ipfs_result = await add_to_ipfs(res)
            const add_to_dapp = await add_meta_entry_to_dapp(regex_key_meta_on_dapp, ipfs_result.path)
            if(add_to_dapp.error){
              console.log("Error happened", add_to_dapp.result)
            }else{
              console.log("add_to_dapp", add_to_dapp.result)
            }
          }else{
            console.log("metadata already found for "+nft_id)
          }
        }catch(err){
          console.log(err)
        }
      }
    }catch(err){
      console.log(err)
    }
  
  return
}

get_event_id_from_nft_id("3N9o4fNhKnVigxGjWv4MuiGXwK94SiQhomm")

Here’s the ipfs.js file required by the example:

let ipfsClient = null
let ipfs_client_dynamic_import = async function(lib){
  ipfsClient = await import(lib)
}
ipfs_client_dynamic_import('kubo-rpc-client')

// signart-external on infura
let host = "ipfs.infura.io";
const projectId = "******";
const projectSecret = "*****";
const auth = 'Basic ' + Buffer.from(projectId + ':' + projectSecret).toString('base64')

const upload = async function(json){
  let result = null
  let ipfs = ipfsClient.create({
    host: host,
    port: "5001",
    protocol: "https",
    timeout: '10m',
    headers: {
      authorization: auth
    }
  });

  let progress_func = function(len) {
    console.log(len)
  }; 

  try {
    result = await ipfs.add(JSON.stringify(json), { progress: progress_func, pin: true, wrapWithDirectory: false, cidVersion: 1 })
  } catch (err) {
    console.log("catched err");
    console.log(err);
  }
  return result
}

module.exports = {
  upload
};

We believe this standard is needed, and it will be added soon to SIGN Art with the upcoming Version 2.

It is already implemented on the testnet and heavily tested on our side.

We are, of course, open to any feedback, especially from any NFT issuer project.

[UPDATE — January 10, 2024]

Based on some feedback received, it was suggested to not only enforce IPFS, even though it is the standard and will remain the preferred option for us. We will adjust the proposed standard as follows:

std_nft_${nft_id}_metadata will become std_nft_${nft_id}_cid and still return the JSON file CID to retrieve it from IPFS. Alternatively, the JSON following the same standard as the IPFS version could be directly stored on the chain as a stringified JSON under std_nft_${nft_id}_json.

Example:

"std_nft_HmKzrrdrznFcZmfhigjTLhjrPXxGyR8fQn1h3eE5HCbV_json": "{"name":"Summer Party DJ Pyrex","description":"Contrary to popular belief, Lorem Ipsum is not simply random text. It has roots in a piece of classical Latin literature from 45 BC, making it over 2000 years old. Richard McClintock, a Latin professor at Hampden-Sydney College in Virginia, looked up one of the more obscure Latin words, consectetur, from a Lorem Ipsum passage, and going through the cites of the word in classical literature, discovered the undoubtable source. Lorem Ipsum comes from sections 1.10.32 and 1.10.33.","image":"ipfs://bafybeibcgaw3fkfddakkaf4hpnjw3v2uikhkskyym7fo2uadw5hgajrfpa/display.jpg","external_url":"https://waveshack.sign-art.app/event/J9ALgp2FbeDGCkqVBsgbUq2BV29LtUZww426V4TQGCrL","attributes":[]}",
"std_nft_HmKzrrdrznFcZmfhigjTLhjrPXxGyR8fQn1h3eE5HCbV_cid": "bafkreifnoed6xstsvsc4w2yclo3hy5jd35nne73334nvah4kk5jwe65k6i",

NFT Platforms will then have the choice to decide to support only the preferred standard or both. Here are the pros and cons we identified:

std_nft_${nft_id}_cid

Pros:

• It is the universally used standard.
• Since NFT media should already be stored on IPFS, this should be easy.
• NFT following this can be transferred to other chains.

Cons:

• Projects need to use IPFS if they are not doing it yet.

std_nft_${nft_id}_json

Pros:

• Does not require IPFS.
• Accessible from other dApps.

Cons:

• Data entries are limited to 5 Kbytes.
• Does not follow the universal standard (Ethereum, BSC, Solana, etc.).
• It can quickly add a lot of entries with duplicated value on dapp storage (ex: NFT with 10 000 editions).

We would still prioritize the use of the IPFS option as it is more universal, it doesn’t add a lot of unnecessary data on-chain, and it is not limited in size. Also, when SIGN Art Ethereum Gateway (https://gate.sign-art.app) eventually accepts any Waves NFT in the future, the JSON on IPFS will be required, as it is needed to send a valid NFT to another Blockchain.

We are still open to any feedback as we will continue to implement and test the standard.

Christophe

https://www.sign-art.app
https://telegram.me/SIGNArtApp
https://twitter.com/signArtApp

In this article, Christophe Verdot, founder of Signature Chain, explains how non-fungible tokens (NFTs) can make a difference in the digital art market.

Fine art is a multibillion dollar market, which, in recent years, thanks to the rise of internet and digital technology, has been drifting from art galleries and auction houses to the web.

Fraud in a digital age

On the one hand, this shift makes art accessible to a much wider audience. However, on the other hand, it raises the issues of authenticity and copyright protection.

Due to digital technology advances, art replication and forgery have, unsurprisingly, become more sophisticated, triggering concerns among sellers and buyers alike. The art market is full of replicas and forgeries that can fool not just your average Joe, but also a seasoned enthusiast. Fraud has been on the rise globally, hitting physical as well as digital art.

To respond to this challenge, artists have begun to certify their digital works on blockchain and distribute them over a peer-to-peer, InterPlanetary File System (IPFS) network. Crypto art, as it’s been referred to, has been gaining prominence thanks to the immutability and decentralization of blockchain.

However, another issue comes up. If a digital image is freely available for viewing or downloading, what value does it have? Producing or buying digital art becomes an uncertain prospect for artists and collectors, respectively, as images can be easily duplicated and plagiarized.

If an art work can be replicated for free, it has a lower market value or none at all. Watermarking authentic works has been a common practice for artists, but advancements in technology are making this measure less effective.

NFT as a solution

To maintain the value of digital items, the blockchain-based concept of “digital scarcity” has been introduced, which is exercised through non-fungible tokens (NFTs). NFT is a cryptographic token representing a unique object or part of it.

An NFT is created as a blockchain transaction that permanently links the token to a unique digital fingerprint or hash on an open, distributed and permanent ledger. The possession of an artwork and a corresponding NFT signifies a verified and undisputable ownership.

NFTs can operate as provenance assuring that an artwork is genuine and providing accurate information on past ownerships.

While online art auctions are notorious for bad provenance due to unscrupulous sellers claiming to have documented ownership of fraudulent art, NFTs emerge as a vital alternative. If an official blockchain address for a specific piece of digital art is published on relevant websites and social media, any user can verify the authenticity of the work.

The immutability of blockchain ensures that an NFT as art documentation has not been altered or falsified.

Tokenized art works are generally presented and shared as HD files, which might be intimidating for some artists and buyers. However, what gives value and scarcity to digital art is not a file itself but the ownership of a “license” in the form of an NFT.

The owning of an NFT gives a buyer or collector the right to display and resell a connected work, but not the creation copyright nor the right to duplicate it commercially. The creator retains all intellectual property rights.

Due diligence still required

Of course, blockchain technology is no magic. Nothing can prevent scam artists from replicating someone else’s piece of digital art, tokenizing it and selling as their own, just like it is the case with physical art.

Still, digital art is available on the internet for the entire world to see and critique. Therefore, fraud can be easily detected. Social media, in particular, have become a powerful tool in that respect. By engaging in fraud, artists put their reputation, public image and potential sales a risk.

On the users’ or buyers’ side, it is still necessary to do minimal due diligence to avoid falling for fraud. Buying blindly from random and anonymous artists is not advisable. Artists should be able to display their portfolio and background, as well as their blockchain address.

SIGN Art solution

On the Waves blockchain, a project called SIGN Art is currently being developed by Signature Chain. The project aims to bring the Waves protocol’s advantages to digital art creators and collectors.

Thanks to its instant transactions and low fixed transaction fees, the Waves blockchain is a perfect fit for NFT issuance.

The current crypto art market is heavily dominated by Ethereum. But the Ethereum blockchain is burdened by up-and-down gas costs, which has been a major source of complaints from collectors and artists.

Over the past year, Signature Chain has developed a certification platform allowing anyone to certify any file or document on the Waves blockchain.

On SIGN Art, the file certification feature will be available soon, allowing creators to certify their works with an option of tokenizing art for selling. SIGN Art could also be used as a portfolio of certified works and/or a digital art marketplace. A beta version of the service is already available on the testnet here: https://beta.sign-art.app.

Read Waves News channel
Follow Waves Twitter
Watch Waves Youtube
Subscribe to Waves Subreddit

Chuyện oái oăm: mua nhà, ra sổ hồng tên mình rồi vẫn không được là chủ nhà

1. Problematic Scenario:

• An individual who has been impersonating the true owner with fake documents. Mr. Ut, the real owner of the house, has lost the property ownership certificate (assuming it could be lost or stolen by the unknown person), he only reports this to a regulator to get a new one without making a request to prevent all ownership transfer transactions related to the house => Traditional identity verification and current property management systems have critical vulnerabilities.

• Notary offices are the authenticator but do not detect the types of documents that have been falsified from the impersonator (falsifying the local police certificate of the impersonator’s ID card number and the number of Mr. Ut’s ID card shown on the property ownership certificate to that from the same person, it is possible that the person pretending to have changed for a new ID card to bypass the buyer and NOTARY OFFICE) caused Mr. Thien (home buyer) to lose trust in the NOTARY OFFICE => The trusted NOTARY OFFICE was proven not to be reliable.

• The court restored ownership of Mr. Ut because he was the real owner of the house and had all the valid proof. When Mr. Thien handed over the money to buy a house from the seller (the person impersonating Mr. Ut), he did not make a notarized delivery document to prove that the payment is valid for the dispute that happened later, so there was no way to claim compensation for the lost money at the NOTARY OFFICE.

2. Comprehensive Solution with Blockchain:

2.1 Why Blockchain?

According to the basic definition of blockchain cited from John Nguyen’s Blockchain Economy book:

“Blockchain is similar to a ledger, which records the history of valid transactions that occur in a system. However, blockchain is a digital ledger, jointly held by multiple parties (each with a copy). Once data has been validated and recorded on the blockchain thanks to the consensus of all computer nodes in the system, there is no way to change it.

The term ‘’blockchain’’ is made up of ‘’block’’ and ‘’chain’’, which is derived from how the system’s design, so that valid transactions occurring in the network will be arranged in the order of the timeline (time-stamp) and is put into a block, then this block is encoded into a hash to close when it meets the conditions set by the system. Then from the hash, it is taken as the basis for connecting to the next new block. Such a system continues to form a chain of blocks that extends to infinity.”

Note, because the blockchain can’t store Blob (big size files), in our solution that we’ll introduce in the next part, blockchain does not store data content directly, but rather records hash as unique encrypted representations for the data’s content into a digital ledger.

For example, a property ownership certificate file of any size (assuming 1 MB) will be hashed by the SHA-256 algorithm into a unique piece of code (hash) that always has a length of 64 alphanumeric characters and alternating numbers, a random fixed size of 256 bits. The hash from two different files will never be the same, any alteration will result in a new hash.

SHA-256 is a one-way cryptographic hashing algorithm that creates irreversible hash back to the original hashed content with whatever computer power we have today. So, there’s no way to directly decode it because the whole purpose of this SHA-256 hash is to be irreversible, making data extremely secure and impossible to be faked.

2.2 Process of the solution

With such superior features, we can offer an effective solution when applying blockchain to data security, anti-tampering and ownership of the right for individuals thanks to certification directly on the blockchain by the competent authority. The process will take place as followed:

Step 1: First of all

• The Land Administrative Management Agency must register its ID address on the WAVES blockchain, this ID address is unique and acts as a digital signature which will be used to digitally sign and issue the property ownership certificate files. This ID address of the Land Administrative Management Agency must be publicly notified to the users to help them determine the validity of the property ownership certificate file(s) when checking licensing information on the blockchain.

• Users also need to create an ID address of their own on the WAVES blockchain. They’ll have to register personal information (KYC) which is associated with this ID address in order to use it to digitally sign a number to purchase and to transfer contracts to prove they’re the rightful owner. This personal ID address of the user will also be shown in the content of the property ownership certificate file issued by the Land Administrative Management Agency.

Step 2: Through a decentralized application, let’s call it the SIGN DApp, built on the WAVES blockchain Protocol, the Land Administrative Management Agency will log in to the SIGN DApp and use their ID address to sign for certificates / validity of the property ownership certificate files.

Step 3: On the SIGN DApp, the Land Administrative Management Agency will receive a “Proof of Certification” file containing the following information:

• Their (LAMA) ID (address) which was used to certify the property ownership certificate file.

• Property ownership certificate file name.

• The time-stamp at which the property ownership certificate file was validated on the WAVES blockchain.

• The hash representing the encryption for the property ownership certificate file(s) that has been recorded in the WAVES blockchain.

• A link so the user can immediately look up the validity of this information directly on the blockchain explorer of the WAVES blockchain.

• A link that allows users to download property ownership certificate files from a decentralized storage system (IPFS) whenever they need it.

The Land Administrative Management Agency then only needs to send the property ownership certificate file and the “Proof of Certification” file to the rightful owner to keep it.

Proof of Certification file of a property ownership certificate issued by the Land Administrative Management Agency.

Step 4: When a buyer wants to verify the validity of a property ownership certificate, confirming who the real owner of a real estate is, he only needs to know the exact ID address of the Land Administrative Management Agency (this information is publicly disclosed by the government) for collation. This requires the owner to provide 1 of the 4 following details to be easily checked on the WAVES blockchain explorer or authentication lookup (verification explorer) of the SIGN DApp:

• The file of property ownership certificate issued by the Land Administrative Management Agency

• “Proof of Certification” file

• The TxID (the code of the property ownership certificate file authentication transaction on the WAVES blockchain)

• The Hash of the property ownership certificate file

When users use the TxID of a Proof of Certification file to check the WAVES blockchain explorer, they will see the authentication information as shown above.

To determine whether a person is the rightful owner of a real estate property, the buyer only needs to do two things:

• Ask the owner to provide 1 of the 4 details listed above to check the authenticity of the property ownership certificate file on the WAVES blockchain explorer or verification explorer of SIGN DApp. Check whether or not the ID address of the current owner is being shown in the content of the property ownership certificate file.

• The buyer uses their ID address to log in and upload the file of the real estate sale and purchase agreement between the two parties onto the WAVES blockchain through the Mutual Agreement feature (a multi-party contract function) on the SIGN DApp (is an application built on the WAVES blockchain Protocol). Next, the buyer enters his ID address, owner’s ID address and ID address of the Land Administrative Management Agency, then signs the sale of contract electronically. The system will then automatically send a request to the ID address of the Land Administrative Management Agency and the ID address of the seller for both parties to sign a confirmation agreement of their purchase agreement.

* Note: only the real owner of the real estate can have the private key of the ID address recorded in the content of the property ownership certificate. They can use their private key to log into the blockchain system and use their ID address to digitally sign real estate sales contracts that they own. So, it is impossible for crooks to impersonate the owner to sell a house and the buyer cannot be deceived by forging papers as the case mentioned at the top of this article.

2.3 Transfer of ownership

When the Land Administrative Management Agency, as a witness, participates in the signing of a real estate sale contract, they also record the transfer in ownership of that real estate. From this facility they will issue new property ownership certificate files and Proof of Certification files to the new owners (the buyers).

In order to prevent the former owner of the property from using the expired property ownership certificate and the invalidated Proof of Certification files to deceive other buyers; avoid the situation of a single property being sold to different buyers at the same time, the Land Administrative Management Agency must:

• Use the revoke function for invalidated Proof of Verification they have issued.

• Add a “revoked” tag to these invalidated Proof of Verification files and a “revoked” tag will be displayed when the user checks them in the WAVES blockchain explorer or verification explorer of the SIGN DApp.

After the certificate has been revoked, a REVOKED tag will have been attached to the Proof of Certification file, when users look it up on the verification explorer of the SIGN DApp they can click directly on the card to check the certificate on the WAVES blockchain explorer as shown below.

In the Call field displayed on blockchain explorer B, the user can see the revoked certification. This proves that the WAVES blockchain has recorded the REVOKED command into the system and the previous Proof of Certification file TxID: 5cXQg8xhDW6Qjm7rWqPWKRYgjhMTnZdunkxZZUfCzaKE is no longer valid.

How can a buyer search for the list of previous eligible owners of the property? Or how can a buyer search for the Proof of Certification files related to a real estate in the past? — This requires the Land Administrative Management Agency when issuing new property ownership certificate files and new Proof of Certification files to be able to attach the information (hash, TxID) of the previous version to the newest version.

3. Summary

How to verify the identity of who the owner of a real estate is:

• The buyer will require the seller to provide the property ownership certificate file and a Proof of Certification file.

How to know if the seller is the owner of the real estate:

• The buyer has to create a three-party contract and uploads the sale contract to the SIGN DApp through the Mutual Agreement feature.

• The buyer first signs digitally, then asks the digital signature (ID address) of the Land Administrative Management Agency in the contract and requires the seller to use the exact ID address recorded in the property ownership certificate file to sign the contract digitally.

To prevent the ex-owner of the property from using previous property ownership certificates and Proof of Certifications which are expired to conduct a fraud transaction:

• The Land Administrative Management Agency must use the revoke functions for invalidated Proof of Verification files they have issued.

• The Land Administrative Management Agency issues new property ownership certificate files and new Proof of Verification files to the new owner.

• The newest Proof of Verification version of a property must refer to its most previous Proof of Verification file.

PART 1
a) Define the project
b) Why use Blockchain?
c) Initiate the project

PART 2
d) Create the HTML for your INDEX views
e) Create a GetData and Settings Classes
f) Create the Index javascript logics

PART 3
g) Create the HTML for your ADMIN views
h) Create the Admin javascript logic
i) Integrate Waves Signer

PART 4
j) Create the Smart Contract
k) Deploy the Smart Contract
l) Conclustion

J) CREATE YOUR SMART CONTRACT

To get the full code of the Smart Contract click here.

On Waves Blockchain, there is 3 types of Smart Contract:

The Smart Account
This is a Smart Contract attached to a Waves Account and the script logic of this contract will check every outgoing transaction (not incoming one)

The Smart Asset
This is a Smart Contract attached to a Waves Asset and the script will process every outgoing transactions that are using this asset.

The dApp
This is a Smart Contract attached to a Waves Account, similar to the Smart Account but the script logic will also includes @Callable function that you will be able to call from outside using the invokeScript transaction

In our project, we use a dApp account, this account will have two Callable functions:

• updateInfos()
  To update the title and description our our page
• addUpdateCase()
  To add or update entry on our data storage

To create your dApp go to ide.wavesplatform.com, this is a convenient online ide for Waves Protocol, a very easy way to start for front end web developers.

From there click on the + on the bottom left:

It will create a dApp Smart Contract template as follow:

You see the 3 first lines these are directives needed to identify the version and type of the contract, don’t touch it. You can remove the 2 commented lines at the bottom (we wont see the Verifier today).

THE “UPDATEINFOS” FUNCTION

We are left with a @Callable function named foo in this new file, all function we want to be able to call from outside of our contract needs to start with a @Callable(i), the i is a global variable accessible inside the function and giving access to the transaction fields, you could call it differently if you wanted.

Be aware that local function, the one you would not allow to be called from outside, should be declared before all the @Callable one’s and without the @Callable on top of it.

Function in RIDE are declared with the key word “func” followed by the name of the function. Please change the function name from “foo” to “updateInfos”, and include two parameters, name and intro:

Make sure to give types to the parameters, here both are :String.
From there we want get the address of the account calling this function, to do that we will declare a new ownerAddress variable with key word “let” and use the global variable “i” to access the caller address with “caller” key word:

let ownerAddress = i.caller

Now that we have the address of the calling account, the title and the description as well, we will write these data on the data storage of the dApp account.

In the current empty WriteSet([]) add the two following DataEntry:

Each DataEntry line will write (or update if the key already exist) a new key/value entry in the dApp data storage, the parameter here are the key (a string) and the value (string, boolean, integer or byteVector) ex: DataEntry(key, value)

When we retrieved our address with i.caller we received the address in byteVector format, key in our data storage needs to be in string format, this is why we use toString() method to convert the address into string.

And thats it, our first @Callable function to update the general infos of the page of the calling account is ready! Was quite easy no?

THE “ADDUPDATECASE” FUNCTION
This function will add just a bit more logics, as you can see, it have a bit more parameter, some as :String and others as :Int, here the full code then we will discuss it:

Same as for the previous function, we declare the ownerAddress.
We also declare a counterNum variable to get the last identifiant used for this calling account, for that we are using what we call a Pattern Matching with the key word “match” followed by a “getter” method.

Here, this.getInteger(address+”_counterNum”) is looking into the data Storage of the dApp for an entry with the key “{address}_counterNum” and that is an Integer, in RIDE dApp Smart Contract, the key word “this” is a reference to the address of the current dApp account, you could also use it that way:

getInteger(this, ownerAddress + "_counterNum")

if you want get data from another account, you would use it as follow:

getInteger("3nHuJg...", ownerAddress + "_counterNum")

Back to our code, if the getInteger() “match”, meaning if the entry exist and is an integer (case c: Int => c) then we attribute the result value to the currentCounterNum variable, if not, then we set it to 0.

Similarly, we will use a match to define the patient ID, we check if an entry with the “identifiant” parameter exist, remember if its 0 it’s a new entry, else its an update.
If an entry exist on the data storage with the key {ownerAddress}_patient_{identifiant}_identifiant” and it’s an Int then we return it to patientID and it’s an update else the patientID is currentCounterNum +1 which is then a new entry with a new auto incremented ID.

After that we build a json with all the data to store it as well on the data storage, this will be usefull to access all data through a unique key request in our Web App. Remember each invoke call send several parameters for a unique case/patient.

We also want to keep an entry per parameter to use the data storage as an open API where you could get all entrie per location only, age only and so on.

Next step, we needs to define how we will update the value of the {userAddress}_counterNum key, ether with the last know identifiant (if we are updating an entry) or the new identifiant (if create a new entry), for that we do:

let updateCounter = if(identifiant == 0) then currentCounterNum + 1 else currentCounterNum

If identifiant parameter was 0 then it was a new entry, meaning we increment the counter of entry for this address by +1, else, the counterNum stay the same.

I’ll use this last piece of code to point out that in RIDE, every if statement needs a then and a else branch, both are mandatory.

We are alsmot there :) Next, we have an if statement again, so? so there will be a then and else right? This one is to check the status parameter, we only allow 3 possible status, 1,2 or 3 (in our project, 1 = confirmed, 2 = recovered and 3 = deceased)

if(status != 1 && status != 2 && status != 3 ) then throw("Wrong status")

else

# code continue here

...

By the way, comments in RIDE only work single line and start with #.

And here we are, now at the last part of our Smart Contract! and its very easy because we will do the same as for the updateInfos @Callable, remember the WriteSet?

So we want write all our data on the storage, and remember, we needs 1 DataEntry(key,value) per data, meaning:

That’s it, our dApp Smart Contract is finished!

K) DEPLOY YOUR SMART CONTRACT

We still have a couple of things to do, first of all, we needs to deploy this Smart Contract on a Waves Account, from the online ide, go to the top right and create a new account:

Select it and copy the Address, go to the wavesexplorer faucet to get some free waves token for testnet:

Enter your address, click that your are not a robot (unless you are one :p) and click “Request 10 WAVES”.

Once you see these waves on your IDE Account, click on “console” at the bottom left and write deploy()

Push enter and the Smart Contract will deploy on the newly created account, this account will then become the dApp and the address of this account is the address you will use in your settings.js for this.dappAddress.

If you see the link to the transaction in wavesexplorer then everything when well!

You can now go back to our Web Application, in the settings.js file and change the this.dappAddress value to this new dApp address, save it, make sure webpack is still compiling and nodemon restarting.
Then go to localhost:3000/admin, connect with waves signer and you will see an empty form, start entering data again, the title and description then a couple of entries and after that, go back to localhost:3000 and you should see these newly added data.

L) CONCLUSION

It was a bit long i know but i wanted to show you a complete real potential Blockchain use case application built from scratch with the front end, back end, the smart contract and everything integrated together.

I didn’t go as deep as i wanted in some parts because it was already quite long but the idea was to help you realise that finally, its not much different than building a website or a regular web app, if you look back over the 4 parts, 1 out of 4 was focusing on the Smart Contract, everything else was regular html, css, javascript, routing, api calls etc. Everything a front end developer know already.

Of course we could improve a lot from here, for example, a way to add entries in mass or even import a cvs of entries, display the waves balance in the admin page etc.

Going back to the Smart Contract, how does RIDE feel? It’s quite easy to understand right? There is of course a lot more to see and do with it but at least now, you know that it is not that complicated after all!

Here a couple of interesting tools to use that i’ll list here even if i wasnt able to include them in the process:

• Waves Dapp this one will allow you to test your smart contract very conveniently through a very simple UI and Waves Keeper
• Waves Keeper this is an alternative to Waves Signer the one we used in our project, the difference is Keeper is a browser extension.
• Waves Documentation of course the official documentation is your friend and very helpfull, you’ll find everything there! If not, ask on telegram
• Waves Explorer we only used it for the faucet but this is a very convenient tools to explorer account, blocks, transaction, dapp storage etc
• Waves Oracle to create oracle for your project

I hope this will help some of you and if you have any question don’t hesitate to ask in comments or on the Waves Developers telegram channel and if you build something on Waves, don’t hesitate to share it with us, we love to see what others are doing!

The STEP 4 code:
https://github.com/christopheSeeka/covstats-tuto/tree/step4

The complete web app code:
https://github.com/christopheSeeka/cov-stats

The webapp example on TESTNET:
https://covtest.sign-web.app/

The webapp on MAINNET:
https://cov-stats.sign-web.app/

PART 1
a) Define the project
b) Why use Blockchain?
c) Initiate the project

PART 2
d) Create the HTML for your INDEX views
e) Create a GetData and Settings Classes
f) Create the Index javascript logics

PART 3
g) Create the HTML for your ADMIN views
h) Create the Admin javascript logic
i) Integrate Waves Signer

PART 4
j) Create the Smart Contract
k) Deploy the Smart Contract
l) Conclustion

G) CREATE THE ADMIN HTML

To get the step 3 code click here.
To get the complete web app code click here.

Now let’s work on the admin page, this page is accessible with the localhost:3000/admin route and display a button “start” which will open Waves Signer popin to let you ether create a new Waves account if you don’t have any yet or choose an existing one.

THE ADMIN VIEW
https://github.com/christopheSeeka/covstats-tuto/blob/step3/views/admin.ejs

Go to the ./views/admin.ejs file and change the content with the following one from this page.

Similarly to the index page, we first include all our needed libraries and css in the <head>.
We have a sort of header (where i could have used a <header> :)) with the title, the description and links to homepage or to waves.exchange. Waves.exchange is where you needs to go get your seed (if you just created an account) or get Waves token to pay transaction fee.

We use here the bootstrap basic accordion element separated in two blocks:

• Block 1 is where you manage the title and description of the page
• Block 2 is where you add or edit entries cases

You would see a <div id=”loader”> in the code which will be used as overlay element when we are waiting for data (when we select an existing entry in the “identifiant” <select> for example)

Something to keep in mind, when we add a new entry, the identifiant list wont be available untill the transaction get at least 1 confirmation (no worries, it’s super fast on Waves).

At the bottom we include our javascript logics bundle call, remember?:

<script src="javascripts/bundle-admin.js"></script>

H) THE ADMIN JAVASCRIPT LOGIC

https://github.com/christopheSeeka/covstats-tuto/blob/step3/src/admin.js

First we needs to add two new libraries here, Waves Signer:

npm install @waves/signer

And the Provider Web:

npm install @waves.exchange/provider-web

These two libraries are required to login with your Waves account and sign every transactions, in the admin page we will use the invokeScript transaction to update infos and to add/update entries.

Now go to ./src/admin.js and replace the content with the content from this page.

We will go quickly over it but only focus on what is related to the dApp calls.

First we import our libraries and classes then to configure Waves Signer we do the following:

Remember, getdata.nodeUrl is getting the nodeURL we entered in our settings.js, we are using a testnet url, for mainnet or stagenet it would be a different url.

Same with the providerUrl used for new Provider(), it also come from our configuration file.

After that we see a resetForm, pretty self explanator, same for displayAlert.

Then we have 4 important listeners:

The “change” event

Listening over the <select id=”identifiant”> element and called every time we choose a differet option in this <select>, here its quite simple, ether we select an existing option and it mean we are updating an entry or we leave it as “New entry” which have the value = 0 and it means we create a new entry.

When we choose an existing entry, this listener will automatically retrieve all the info with our getdata.getDataByKey() method with the proper key as argument and display the data in the different fields.

We could just have retrieve the json entry (you will see that in the next part) but i wanted to show you a different way, getting each separated data from our Node API.

The “login” event

This one is linked to the <button id=”login”> element and is calling the Waves Signer method signer.login() which open the signer popin where you create/choose your account. Once you select an account, the callback will:

• Get the name/title of the page and display it
• Get the introduction texte of the page and display it
• Retrieve all the entry id associated to your address and populate the <select id=”identifiant”> element with it

The Waves Signer login method work as follow:

The “addEntry” event

This is called every time <input id=”addEntry”> is clicked, the callback will define if we add a new entry or update an existing one, based on the <select id=”identifiant”> selection. Then it will create the needed parameters for our invokeScript transaction, which is the transaction type we needs on Waves Blockchain to call our dApp Smart Contract function (that we will create in part 4 of this series).

Here our data object:

dApp is the address of the dApp account with our smart contract attached to it, we pass here the dappAddress that we get from our settings.js file

call.function this is the name of the function we want to call on the Smart Contract/dApp account, here it’s addUpdateCase

call.args is an array of object with all the different data from our form that needs to match the parameters of the dapp function (in exact order) we are calling, note that you needs to define the type (integer, string, boolean or bytearray) aside of the value.

Once our data are ready, we will sign these data and broadcast them to the Blockchain through the Node API.

To sign data with signer you just have to use the following:

Basically, you use the invoke method of Waves Signer (each transaction type have its own method), you call this invoke method with your data object as parameter and then you attach the broadcast() method right after it.

Signing data don’t send them to the blockchain, it only sign the data with your private key (you sign with your Waves account), once you signed, you needs to send these data to the Blockchain, which is what broadcast is doing.

Since its a promise, you simply can add your .then() and .catch() after broadcast() to do your stuff once its sent.

You will see a checkStateChange function too in my code, i wont go over it for now as i don’t want overcomplicate things, in short, its because since we added a new entry, we need to wait it to be confirmed and then update or <select id=”identifiant’> list.

The “accountInfo” event

This one is called when you click on the <input id=”accountInfo”> element, in the first form of our accordion element, to update the title and description, it work exactly like the previous event, meaning it create a data object with data and use the same dApp address.

The call.function here will change, we want call another one, which is “updateInfo” and then the call.args will simply get the title and description data from the form fields.

We sign the data with signer.invoke() method again, we broadcast it and we clear the form once its done.

At the end of the ./src/admin.js file you’ll see a loadResize function, this is juste to adjust the layout on different screens.

You should now be able to go to localhost:3000/admin, click on “start” and login with your account (or create a new one), if you don’t have any testnet waves token, go get some here.

Try to enter a “Page name” and “Introduction” once connected, then click UPDATE INFOS, after that, click on “ADD OR UPDATE ENTRY” to switch tab and fill the form, click on ADD NEW CASE, once its done, you should see your data at localhost:3000/your_waves_address

If you want configure the Web App on your Waves Address, you can change this.userAddress in settings.js with your own address (the one you used to add an entry); then localhost:3000 will directly display your data.

And that’s it for our STEP 3!! Almost done! we have one more step to go!

In STEP 4 we will see the dApp Smart Contract, go over it together, see how to deploy it then we will configure our Web App to use this dApp instead of the current one.

The STEP 3 code:
https://github.com/christopheSeeka/covstats-tuto/tree/step3

The complete web app code:
https://github.com/christopheSeeka/cov-stats

The webapp example on TESTNET:
https://covtest.sign-web.app/

The webapp on MAINNET:
https://cov-stats.sign-web.app/

PART 1
a) Define the project
b) Why use Blockchain?
c) Initiate the project

PART 2
d) Create the HTML for your INDEX views
e) Create a GetData and Settings Classes
f) Create the Index javascript logics

PART 3
g) Create the HTML for your ADMIN views
h) Create the Admin javascript logic
i) Integrate Waves Signer

PART 4
j) Create the Smart Contract
k) Deploy the Smart Contract
l) Conclustion

D) CREATE THE INDEX VIEW

To get the step 2 code click here.
To get the complete web app code click here.

Let’s start with the views, remember we already defined ours routes for index and admin, we now needs to builds these templates, lets start with index.ejs.

What do we needs and how i structured it:

Edit button
This button is a link to the admin page, anyone can go there and connect with his own Waves account, he then can start add data.

Remember, the web app is deployed with a settings.js file (that we will create later) so the root url of the Web App will only show data based on the account defined in this settings file but anyone can have his own page simply by adding his account address (the one he used to add data in the admin page) after the root url.

Title
The title for the displayed page, this is administrable in the admin page, it can be the name of an university, a city, an hospital or anything to identify the data source.

Description
Here you can describe the data, for example “Welcome to the COVID19 Tracking Data page of the XXXX City”

Graph
A graph displaying the number of cases by day, this is to give a visual about the situation, to see quickly if it’s going up or down.

Filters
You can filter every columns of the table to group the data according to your own criterias

Widgets
Four separated widgets will display the counts of Total, Confirmed, Recovered and Deceased Cases, each identified with a different color.

Data in a sortable table
Pretty self explanatory, this will display all the data and allow you to sort them on each columns.

Pagination options
Basic pagination options.

Links
Here will be displayed the address of the dApp account, which is where the displayed data are stored as well as the owner account address, which is the address of the account that is managing these data.

THE CSS

To keep this tutorial “short”, i wont spend any time on the css part, just open the style.css file in ./public/stylesheets/ and add the content from this file.

THE INDEX HTML

https://github.com/christopheSeeka/covstats-tuto/blob/step2/views/index.ejs

We include in this page several libraries needed for the different displays such as dataTable, CanvasJs, Jquery, Bootstrap and our fonts from google.

Check the <head> section of the index file to see these changes:

Then we strucure the <body> part with 4 container:

You will find at lines:

• 21: the edit button, the title and and the description, these data will be retrieved from the blockchain API
• 30: the widgets, this include a <div id=”chartContainer”> element, this is empty and will receive the chart dynamically created later based on the dApp Storage data.
• 64: the table that will contain all the data, the tbody of the table is empty and will be populated later with dynamic data from the Blockchain Data Storage through Node API calls.
• 89: the footer that will contain our links, some link will be added dynamically later.

Get the code here and use it as replacement for the ./views/index.ejs file

Also create a canvasjs.min.js into ./public/javascripts/ and add in it the content from this file.

Our index view is now ready to receive data, before moving to the associated javascript logics, we will create 2 simple classes to simplify our work.

E) GETDATA & SETTINGS CLASSES

Here we will create two classes to simplify the Web App configuration and the get requests on the Node API.

THE SETTINGS CLASS
https://github.com/christopheSeeka/covstats-tuto/blob/step2/settings.js

To allow easy configuration of the Web App, i made a settings.js file at the root of the project, this file will be imported in our getData class and used in the different javascript logics later.

First create a new file named settings.js at the root folder and add the following:

This class allow us to define the following:

• this.network is the network we want to use, ether “T” for Testnet, “W” for Mainnet or “S” for Stagenet.
• this.nodeURL is the Node API URL for our get request on the data storage.
• this.providerUrl is the url of the Waves Signer provider we want to use, here is waves.exchange, which is where your account will be manageable.
• this.userAddress is the address of the account managing the main data (the one displayed on the root url). Leave it by default for now.
• this.dappAddress is the address of the dApp account where the data are validated and stored. Leave by default for now.

Then we have a getter to easily get these data from anywhere.

THE GETDATA CLASS
https://github.com/christopheSeeka/covstats-tuto/blob/step2/src/getData.js

To easily get our data i created another small class that will do get requests to the Node API everytime we needs data.

Create a file named getData in ./src/getData.js and add the following content from this file:

Here we import the settings file we just created earlier and initiate it in a “config” variable. Then we start writting the class, in the constructor, we match the fields based on the settings file using the getter (config.get())
There is also an “explorerSegment” field we didn’t mention yet, you will see that later.

Then we have a conditional block that will check if we have a Waves address as url segment (well, it check if there is something, we could add a isAddress verification method later as improvement), if we do, then we use this as userAddress to get the data, if not, we use the userAddress defined in our settings

Remember, if you access the root url of the webapp, it use the userAddress you defined in setting, if we access the url/address then it use this address from the url segment.

Finally we have the async method that will call the node API with a simple fetch get request using the node url we defined in our settings.js (https://nodes-testnet.wavesnodes.com). To this nodeUrl we attach the path of the end point we needs (see the node api end points list here) and the dappAddress then we use the “ match” method with the key we are looking for, exemple:

https://nodes-testnet.wavesnodes.com/addresses/data/3NBbHi3Vj5yt37Yv9XZtfwMy7KnZUWSY3uM?matches=3NBSNZiKU3h51dyTyMGX2sPdPfyjqBKf2F4_patient_(.*)

Note the (.*) at the end here, which mean anything after our string is allowed.

F) THE INDEX JAVASCRIPT LOGIC

https://github.com/christopheSeeka/covstats-tuto/blob/step2/src/main.js

Now we needs to write our javascript logics that will basically retrieve our data from the dApp Data Storage and do all the data processing, for that we will use our getData class.
We will then inject all these data into our index html.

Remember to start your watchers if they are not active from last part, open a first terminal and run:

npm run watch

and a second one where you type:

nodemon

First of all, there is one more plugin we needs to add and its sanitize-html, we want clean up all string from any possible javascript code to avoid XSS attacks, at least for the front end display. If you use public data from Blockchain i would recommand to always sanitize it before displaying.

Open a 3rd terminal and run the following command:

npm install sanitize-html

Now, go to ./src/main.js and copy the code from this file into your file, remember ./src/main.js is the file compiled into ./public/javascripts/bundle-main.js which is then included at the bottom of our index.ejs.

The code is a bit long so i wont go in detail over everything but i commented the key points:

What are we doing hre:

So, first we import sanitize-html and our getData class so we can use the getDataByKey method.

We then declare some variable and start retrieving our data, example:

Here we pass the {userAddress}_name as parameter of getDataByKey, this is the key we are looking for in the data storage of the dApp, it will give us the name/title of the page, we then inject it into the html <h1 id=”title”>.

We do the same for description, with the key {userAddress}_description and inject the result into the <p id=”introtop”>.

After that we see two functions, initTable() and initChart(), i wont go into details as it would be very long but in short, they get the data from the view and will filter, sort and organize all of them as needed.
But before that, we needs to retrieve and process all the data from the data storage and add them to the view, which is what next code do with another getDataByKey call.

You see here that we use the key {userAddress}_counterNum, this is because each account using the dApp storage will have an auto incrementing “counter” that will serve as identifiant for new entry. So we do a call on this key, if there is no result for {userAddress}_counterNum that mean no data, else, there is data and we start processing them, generating each lines of our table and add it to the view. Then we populate our different counting widgets, our footer urls (this is where we use the explorerSegment because depending of the network we use, it would change) and finally we call our initTable().

InitTable() will initiate the dataTable plugin and if all go well, end by calling the initChart plugin, from there canvasJs will do his job to generate our chart and inject it into the <div id=”chartContainer“> element.

If you go to localhost:3000 you will see the same page as https://covtest.sign-web.app/, for now it is using the default userAddress and dappAddress, later on you will use your own.

And that’s it for the index!!

Was a bit of a work! but remember, i said it will be “quite easy”, easy is not necessary short :) Here we are building a complete, working Blockchain Web App from scratch so it require a bit of work of course.

In the STEP 3 we will work on the ADMIN page and implement Waves Signer! Stay tuned and if any question, comment or message me.

The STEP 2 code:
https://github.com/christopheSeeka/covstats-tuto/tree/step2

The complete web app code:
https://github.com/christopheSeeka/cov-stats

The webapp example on TESTNET:
https://covtest.sign-web.app/

The webapp on MAINNET:
https://cov-stats.sign-web.app/

PART 1
a) Define the project
b) Why use Blockchain?
c) Initiate the project

PART 2
d) Create the HTML for your INDEX views
e) Create a GetData and Settings Classes
f) Create the Index javascript logics

PART 3
g) Create the HTML for your ADMIN views
h) Create the Admin javascript logic
i) Integrate Waves Signer

PART 4
j) Create the Smart Contract
k) Deploy the Smart Contract
l) Conclustion

In this article series i want to show you that despite the possible complexity of the overall Blockchain technology, developping a web application using Blockchain is still quite accessible for a front end web developer.
Of course it helps to understand in details every aspects of Blockchain (blocks, transactions, asymetric keypair etc.) but it is not necessary needed to start building.

Simply imagine things like this:
Webapp > API > Middleware > Database

Thats it, Webapp is your regular web interface, API will be offered and accessible via the public Node (you could have your own node later eventually), the Smart Contract will act as a middleware and the data storage of the blockchain will be your database.

If you know how to use an API and install libraries, then all you needs to learn is RIDE (Waves programming language) and it’s really easy, especially in most projects, the Smart Contract often only represent a small piece of the work, everything else will be what you know already eg. the HTML / CSS, Routing, API calls etc.

A) DEFINE THE PROJECT

To get a concrete example, we will build a simple web application tracking COVID19 Data for any entity eg. University, Hospital, City etc.
Keeping track of the COVID cases will be a necessity for upcoming months untill it disappear completely so it will be a good example for this tutorial.

You can find the working Webapp here:
TESTNET: https://covtest.sign-web.app/
MAINNET: https://cov-stats.sign-web.app/

The main idea is to have a web app that display a front page with all the tracking data like chart, filters, table etc.

And a backoffice to administrate these data

The webapp will use a dApp (Smart Contract) on Waves Blockchain to validate and store these data.

The webapp will also use Waves Signer library to allow any Waves account to sign transactions.

When you use a Blockchain, you needs what we call transactions, these transactions carry your data and are sent to the nodes through the node API and then are included in blocks, these blocks are linked together one after the other and it is what make the Blockchain, a chain of blocks. Smart Contract verify the validity of these transactions.

There is no fee in our project aside of the regular transaction fee going to the miners and that are needed to process any transaction on Blockchain.

The web app will offer two options for anyone to have their own tracking page:

• You can simply use the main entry point:
  https://covtest.sign-web.app/ (for TESTNET)
  and click “EDIT PAGE” button, here you will connect with your Waves account and start adding data. Your page will then be accessible with your data only at https://covtest.sign-web.app/{your_waves_address}
• You clone the repository from Github and install your own version on your server, you will edit settings.js with your owner address (Waves account used to add data) and the dApp account. dApp account can be ether the public dApp address 3N5NLAqd9w7sNuUnjfWq7mzW3bherD6uZmn (for TESTNET) or your own dApp address (you will then deploy the smart contract on it).

Any entity can then host its own web app or use the public one and display their official Waves address + link to this tracking page into their official website.

Having this link and address on official website of the entity you know then that the data are officials.

B) WHY USE BLOCKCHAIN?

Why would we choose to use blockchain for this? There is several reasons and you should always ask yourself “why blockchain” before starting, blockchain is NOT the answer to everything, it is slower than centralized database, data are public and immutable and it involve transaction fees.

• We want give opportunity to anyone to see the data in real time and track any possible changes in a totally transparent manner
• We won’t have to develop a GET API or a secured Login/Account system, both will be available by default with Waves Signer / Waves Account and the Blockchain Node API
• We want give opportunity to anyone with a Waves account to start its own tracking page easily
• We want these data public, immutable and decentralized for future reference
• With all the above, an entity using the dApp cannot modify any data to claim different results later or shut them down in weeks, months or years

C) START A NEW PROJECT

To get the code of the step 1 click here.
To get the code of the full web app click here.

Keep in mind that this project is open source and available for anyone to use but the main goal when i built it was education.

I limitate the use of libraries/tools like Typescript, Sass, Waves Transactions, Surfboard as well as framework like React or Vue (i prefer work in Vanilla JS in general anyway).
I also limitate the code splitting in several files or anything that would over complexify the structure because the goal is to keep it accessible to any front end developer level as well as helping understand as much as possible what really happends.
I heavily commented the code on that purpose.
This project can most certainly be improved.

In this tutorial, i’m going to build the webapp using the following technology and libraries:

For the webapp :

• VSCODE as ide
• NodeJS and ExpressJS for the routing & architecture
• Webpack & Babel to allow us working with es6
• Nodemon to simplify the process
• HTML / CSS and Bootstrap for the views
• Vanila javascript for the programming logics
• Waves Signer for the signature of transactions
• Jquery, DataTables and CanvasJs for data display and graph
• Sanitize-html to sanitize the data we receive from data storage

Lets start!

Let’s first install all the needed libraries, of course i assume that you already have nodejs and npm installed here, if not please follow these steps

Create a new empty folder and do a right click in it “open with Code”, this will open the VSCODE editor.

From there, in VSCODE, open a terminal and type the following to install Express JS:

npm install express -g

Now, we will initiate the new project with:

express --view=ejs .

We are simply telling express to create a new project using EJS as view engine, the . mean we create it at the root of the folder we are currently in.

You should now have the following files and folders structure as well as a ready to use app.js file:

To install dependencies just use the following command:

npm install

We now needs to install Webpack and Babel that will allow us to work in es6:

npm install webpack

In your packages.json, modify the scripts section as follow:

"scripts": {
  "start": "node ./bin/www",
  "build": "webpack -p",
  "watch": "webpack --watch"
}

We have 3 scripts here, “start” is the regular npm start that lunch our webapp, “build” will use webpack to compile our es6 javascript into es5 bundle and “watch” will watch any change and compile without the needs to lunch a build command manually each time.

Now, we will install babel:

npm install -D babel-loader @babel/core @babel/preset-env babel-polyfill

Now, create a file named webpack.config.js at the root of your project and add the following:

As you can see in the entry section of this file, we will needs to create a ./src folder with two files, main.js that will be the javascript code for our index page and admin.js that will be the javascript code for the admin page, the admin page is where anyone will be able to connect with a Waves account and manage data related to this account.

In the output section, the compiled code (from EcmaScript 6 to EcmaScript 5) will be renamed as bundle-[name].js and save in the public/javascripts folder, all your front end assets will be in this ./public folder, meaning:

./src/main.js will compile as ./public/javascripts/bundle-main.js
./src/admin.js will compile as ./public/javascripts/bundle-admin.js

Please create a ./src folder then in this folder, create 2 files, main.js and admin.js, leave it empty for now.
“./” represent the root of your project, don’t include it in the folder name :)

You will also notice in this webpack.config.js file the use of babel loader, for this, we will also have to create another file at the root of our project and call it .babelrc don’t forget the . at the begining.

In this .babelrc files, simply add the following:

{
"presets": ["@babel/preset-env"]
}

We also needs a couple more libraries to avoid runtime errors on async/await:

npm install --save-dev @babel/plugin-transform-runtime
npm install --save @babel/runtime

Update your .babelrc as follow:

{
  "sourceType": "unambiguous",
  "presets": ["@babel/preset-env"],
  "plugins": ["@babel/plugin-transform-runtime"]
}

You can now simply write in the console:

npm run watch

On first run it will ask you the following:

Do you want to install ‘webpack-cli’ (yes/no)

Just type “yes”

You should see the following, which mean everything is working as expected and the files are compiling:

Open a second terminal (you want keep the webpack watch terminal running) and we will install another important library to simplify our development, type:

npm install -g nodemon

Then just type the following in terminal to run nodemon:

nodemon

Nodemon is a very convenient tools that will restart your server after every changes in any file. We have now 2 terminals running, one with webpack watching your files and one with nodemon restarting the server everytime a file change.

Now your files structure and packages.json architecture should look like this:

Lets now create our routes, route will define what happens when we call a certain url. By default, we have 2 routes in ./routes, index and users.

The index is as follow:

We dont needs users route but an admin route, lets rename the ./routes/users.js file as ./routes/admin.js then change the content as follow:

Im not going to explain everything when it come to nodejs / Express or even the regular javascript i’m going to write later, it is out of the scope and would take too long but remember you always can ask questions in comments section and there is plenty of tutorials already on these matter.

Now go back into your app.js and change your routes related code as follow:

We change line 7 as:

var indexRouter = require("./routes/index");

line 8 as:

var adminRouter = require("./routes/admin");

line 22 and 23 become

app.use("/", indexRouter);
app.use("/admin", adminRouter);

And added at line 24 the following:

app.use("/*", indexRouter);

In short:

• If we call webapp_url/ or webapp_url/* it will use the index Router (./routes/index.js) which will render the index view (./views/index.ejs)
• If we call webapp_url/admin it will use the admin Router (./routes/admin.js) which will render the admin view (./views/admin.ejs)

webapp_url/* where * represent anything (anything else than admin since a route is defined for admin) and we will use it as * = waves address, a parameter we will needs to display data for any waves account.

So then we needs to also adjust our views.

Open the ./views/index.ejs and change the content with:

Simply duplicate ./views/index.ejs for now and rename it as admin.ejs, in this new file replace “index” by “admin” in the texte.

Notice that we added the following right before the </html> of the ./views/index.ejs file:

<script src="javascripts/bundle-main.js"></script>

Change it into ./views/admin.ejs for the admin view file:

<script src="javascripts/bundle-admin.js"></script>

If everything is working as expected, you can now access your webapp at localhost:3000

If you want adjust the config and change the port for example, go to the ./bin/www file

Test that everything is compiling as expected, for that, go to ./src/main.js and type:

console.log(“Index Rock!”)

Save the change and go back to your webapp, localhost:3000, click right then “inspect”, go to console tab and you should see there “Index Rocks:”.

Try the same with ./src/admin.js and type:

console.log(“Admin Rock!”)

Save it and go to localhost:3000/admin, check the console!

If both message are showing, then you Rock too! You completed the first step on how to create a Webapp using Waves Blockchain Protocol and have your architecture ready.

The STEP 1 code:
https://github.com/christopheSeeka/covstats-tuto/tree/step1

The complete web app code:
https://github.com/christopheSeeka/cov-stats

The webapp example on TESTNET:
https://covtest.sign-web.app/

The webapp on MAINNET:
https://cov-stats.sign-web.app/

In the upcoming STEP 2, we will work on the html and javascript logics of the index page, stay tuned!

Qu’est ce qu’une Signature ?

Pour pouvoir envoyer des transactions ou des blocks sur la Blockchain ils
doivent être obligatoirement signés.

Lorsque l’on crée une transaction, qui n’est qu’un ensemble de données sous forme d’objet (voir schéma 1 ci dessous), nous utilisons notre clé privée provenant de notre seed (phrase secréte de 15 mots) afin de signer de manière digitale cette transaction.

Signer une transaction va ajouter une propriété “Proof” dans l’objet de cette dite transaction, cette entrée est un simple tableau qui contiendra notre signature, preuve que nous avons bien signé ces données avec notre compte et qui pourrait contenir jusqu’à 7 autres signatures (à noter que ce tableau n’est pas limité qu’à des signatures, on pourrait passer d’autres infos) dans le cas d’une transaction multisig.

A noter que les exemples ici sont basés sur la Blockchain Waves et bien sur les informations diffèrent d’une Blockchain à l’autre même si les fondamentaux restent généralement les même.
Sur la Blockchain Waves vous verrez parfois une propriété “signature” au lieu de “proof”, c’est en fait parce qu’en version 1, au début de la Blockchain Waves, on ne pouvait passer qu’une seule et unique signature. Les transactions en version 2 remplacent cette propriété par “proof” et permettent donc du multi-signature.

Dans l’exemple “schéma 1” nous passons uniquement les paramètres requis par la librairie utilisée, ici waves-transactions pour NodeJs qui elle se charge d’ajouter les paramètres par défaut manquant.

Une fois la transaction signée, elle est “propagée” (broadcast) en étant transmise au réseau de node via l’une d’entre elle et via la methode “broadcast()” ici pour la librairie utilisée. La transaction passe par l’UTX Pool en attendant d’être traitée et incluse dans un block.

Le principes est relativement similaire pour les blocks, en effet, un compte qui mine des blocks est un simple compte Waves avec seed, paire de clés et adresse et il signe les blocks générés avec sa clé privée.

Pour rappel, une node peut miner des blocks des lors qu’elle a au moins 1000 waves sur sa node, soit directement sur son compte soit via le leasing (principe de location de waves). Dans un prochain tutorial nous verrons ensemble comment installer et configurer votre propre node. Cependant n’importe qui peut avoir sa propre node, sans les 1000 waves, ce qui donnera une node de validation de block mais qui ne mine pas.

Un block contient plusieurs informations avec entre autre, outre les transactions validées, une référence au block précédent, un block id qui est le hash de deux éléments combinés, à savoir le block id du block précédent + le hash de toutes les transactions du block en cours.

Ce block sera également propagé sur le réseaux de nodes ou celle ci vont valider la validité de la signature du block mais aussi que ce block avait bien le droit de miner un block sur la base du consensus de la Blockchain.

Points clés :

• Chaque transaction est signé via la clé privée de l’émetteur
• Chaque block est signé par la clé privée du compte de la node
• On peut également signer n’importe quel données avec la clé privée
• Les transactions en version 1 utilisaient une signature unique
• Les versions 2 utilisent un tableau “Proof” contenant 1 à 8 signatures
• On vérifie la validité d’une signature via la clé publique du compte

UTX POOL (Unconfirmed Transactions) :
Les transactions non confirmées

Il y a une étape importante entre le moment ou la transaction est envoyée et son traitement par une node.

Sur le schéma précédent (schéma 2) nous voyons à gauche le processus de signature d’une transaction par un compte qui ensuite propage cette transaction signée vers la node qui mine et celle ci vérifie les transactions.

A droite du même schéma, nous voyons alors le processus de validation d’un block, ce qui correspond en fait au détail de la dernière étape de la partie gauche “Node qui mine”.

Il y a en fait une étape intermédiaire qui est l’UTX Pool, une sorte de “salle d’attente” ou les transactions transitent en attendant d’être traitées par la node qui obtiendra le droit de miner un block.

Il est donc important d’en tenir compte, en effet, nous pourrions avoir l’idée de passer des choses “secrètes” dans nos transactions, des données à usage unique comme par exemple des mots de passe ou code pour obtenir xx free tokens et nous comparerions ces codes aux hash équivalent stockés sur l’espace de stockage du compte. Mais du fait de l’UTX Pool n’importe qui pourrait voir ces informations en “écoutant” les transactions non confirmées et ainsi les utiliser avant même que la transaction initiale soit traitée ou encore si elle était rejetée pour une raison quelconque.

Points clés :

• Chaque transaction passe par l’UTX Pool
• Une transaction peut y rester plus ou moins longtemps
• La transaction est donc visible avant son traitement
• De ce fait on ne passe pas de mot de passe même à usage unique
• Toutes les transactions de l’UTX Pool sont traitées

N”hésitez pas si vous avez la moindre question ou un sujet en particulier que vous aimeriez voir traité sur notre chaîne Youtube.

Pour voir notre vidéo en lien avec cet article c’est ici :
https://www.youtube.com/watch?v=KBy2P17hT1M

PROCHAINES VIDEOS

12 février Waves explorer et IDE, nous verrons en détail chacun des éléments de l’explorateur Waves en ligne puis nous verrons l’ensemble des possibilités offertes par l’IDE en ligne qui simplifie grandement le développement de dApp et Smart Contract

15 février Waves Keeper, cette extension navigateur, similaire à Matamask, permet aux utilisateur de votre application Blockchain de gérer l’ensemble de leurs comptes directement depuis le navigateur et de manière entièrement sécurisée.

19 février Préparer son environnement de développement local est la suite logique après s’être familiarisé avec l’IDE en ligner. Nous verrons comment installer l’ensemble des éléments, à savoir l’extension Waves pour VS CODE, une node privée via Docker, le plugin Surfboard etc.

22 février Utiliser son environnement précédemment installer et comprendre l’ensemble des fonctionnalités de Surfboard pour la création, la compilation et un déploiement rapide de vos smart contract

25 février RIDE V4 et Waves node 2.0 arrivant sous peu, nous passerons en revue l’ensemble des changements liés à ces nouvelles version, pour RIDE mais aussi pour le protocole Waves.

Suivez nous et posez toutes vos questions sur :

Youtube : https://bit.ly/37cWEAq
Telegram : https://t.me/wavesdappsFR
Twitter : https://twitter.com/WavesDevFr
https://www.wavesplatform.com

Cet article est la retranstription du wébinaire du samedi 25 janvier 2020 disponible à l’adresse suivante :

https://www.youtube.com/watch?v=Vvc0Xh8DuFE

Qu’est-ce qu’une Blockchain ?

Une blockchain est simplement une base de données persistante, immuable et décentralisée.

Une Blockchain c’est un enchainement de blocks liés entre eux par l’utilisation de hash cryptographiques.

Une Blockchain à un « Height » et chaque block qui la compose à un « height » également.

Le « height » d’une blockchain est le numéro du dernier block dans la chaine de blocks, le height de chaque block et simplement son propre numéro de block dans la chaîne.

Les blocks contiennent des transactions.

Une Blockchain est donc composé d’une séquence de blocks mais aussi d’un réseau qu’on appelle Blockchain Network composé de « Nodes ».

Chaque Node représente une copie complète de la blockchain, de l’ensemble des blocks qui la compose et donc aux données identiques, sur un server ou un ordinateur différent.

Il existe ce qu’on appelle le « Chain ID », un paramètre de configuration de la blockchain pour définir le type de réseau de celle-ci, il en existe 3 sur la blockchain Waves :

• StageNet (ChainID 83 / 0x53 / S) *
• TestNet (ChainID 84 / 0x54 / T)
• MainNet (ChainID 87 / 0x57 / W)

*(decimal / hexa / ASCII)

Les différents réseaux de la Blockchain Waves

MAINNET
Est le réseau original et fonctionnel ou les transactions utilisent les cryptocurrencies ayant une vraie valeur économique, en bref, le Mainnet représente la blockchain Waves actuelle.

TESTNET
Est une version ayant toutes les fonctionnalités du Mainnet mais utilisant un token fictif, sans valeur économique et un réseau séparé du Mainnet, le Testnet, comme son nom l’indique est uniquement pour les test durant le développement, ce qui évite les pertes en cas d’erreurs de code.

STAGENET
Est le réseau expérimental, il inclus les même fonctionnalités que le Mainnet et Testnet mais aussi les possible futures fonctions testées ici avant d’être déployées sur les autres réseaux.

Qu’est-ce qu’un Block ?

Un block représente un maillon de la Blockchain.

Un block contient entre autres des transactions et peut avoir une taille de block de 1Mo maximum.

Le délai entre chaque création de block est de 1 minute et 5 secondes entre les micro blocks (Waves NG).

L’identifiant d’un block est le résultat du hashage cryptographique de deux éléments combinés :

Le block header contient une référence à l’identifiant du block précédent.

Le block header contient également le hash de l’ensemble des transactions que sont incluse dans celui ci

L‘identifiant d’un block est en fait le hashage de l’identifiant du block précédent + le hash de l’ensemble des transactions du block en cours.

C’est donc ce qui lie chaque block entre eux via le hash cryptographique du block précédent et rend la Blockchain immuable, si nous voulions modifié un block dans la chaîne il nous faudrait alors re miner l’ensemble des blocks suivants, ce qui est bien sur totalement impossible sans être détecté et demanderait beaucoup de temps et d’énergie.

Qu’est ce que Waves NG et les Blocks Fluides ?

La Blockchain Waves utilise le Protocol Waves NG qui provient de Bitcoin NG et utilise le principe de block fluides ou chaque block est composé de :

• Un Leader block aussi appelé Key Block ou header, cet header ne contient pas de transactions mais plusieurs informations, notamment : une référence unique au block précédent qui est un hash cryptographique provenant du header du précédent block.
  Une fois le leader sélectionné, il peut miner pendant 1 minute (blocktime)
• Multiple micro-block qui contiennent les transactions, un micro-block est ajouté par le Miner toutes les 5 secondes pendant 1 minute et contient jusqu’à 200 transactions par microblock

Consensus de la Blockchain Waves

Le consensus représente les règles établies entre toutes les nodes du réseau pour choisir le prochain validateur de blocks.

Il existe différents types de consensus sur les différentes Blockchain, les plus populaires sont :

• Proof Of Work (POW)
• Proof Of Stake (POS)

On peut visualiser cela de manière simplifiée, et donc pour arriver au consensus, avec le Proof Of Work, toutes les Nodes du réseau doivent essayer en même temps de résoudre un problème mathématique donné, la première à le résoudre « gagne » et peut Miner le block suivant.

Pour le Proof Of Stake, au lieu de faire travailler toutes les Nodes en même temps, on va en sélectionner une et elle seule va être chargée de résoudre le problème. La sélection est basée sur différent paramètres, notamment le montant de tokens détenue par la Mining Node.

Waves utilise le Lease Proof Of Stake, qui reprend les principes du POS mais avec un principe supplémentaire de Leasing. En effet pour pouvoir participer au réseau en tant que Miner de block il faut d’abord avoir un nombre de tokens donné, pour la Blockchain Waves il s’agit de 1000 Waves. Le principe de Leasing permet aussi aux personnes n’ayant pas ces 1000 Waves de participer au Mining en les louant a une node ayant elle au moins 1000 Waves et ainsi d’obtenir une part des gains « reward ».

Il est possible d’avoir sa propre node sans avoir les 1000 Waves requis, cette node devient alors uniquement une Node de validation qui validera les blocks et transactions mais ne mine pas et ne reçoit donc pas de reward.

La cryptographie

La cryptographie représente une part importante de la blockchain que ce soit pour la création des clés publiques et privés, de l’adresse, de la création de blocks ou de la signature de transactions.

Points clés de la cryptohaphie utilisée sur la blockchain waves :

Blake2b256 et Keccak256 pour la création de hash cryptographique exemple : keccak256(blake2b256(account seed bytes)) = H4do9ZcPUASvtFJHvESapnxfmQ8tjBXMU7NtUARk9Jrf

Curve25519 pour la création/vérification de signature

Base58 pour la conversion de tableau de données en string exemple : “teststring” = [5, 83, 9, -20, 82, -65, 120, -11] = 7bWpTW

Les comptes

Un compte c’est simplement une seed dont découle une paire de clés public et privée ainsi qu’une adresse, le tout liés à la Blockchain via la cryptographie et utilisé pour signer les transactions et les ordres.

Chaque compte est composé d’une seed unique, une phrase secrète de 15 mots minimum générés aléatoirement, exemple :

manage manual recall harvest series desert melt police rose hollow moral pledge kitten position add

De cette seed sont générés la clé publique et la clé privée via différents hashages cryptographiques :

Clé privée :
3kMEhU5z3v8bmer1ERFUUhW58Dtuhyo9hE5vrhjqAWYT

Clé publique :
HBqhfdFASRQ5eBBpu2y6c6KKi1az6bMx8v1JxX4iW1Q8

Comme son nom l’indique, la clé privée ne doit jamais être partagée, au même titre que la seed / Phrase secrète. L’une ou l’autre sont nécessaires pour accéder à son compte et signer des transactions.

Comment obtenir un compte

Il existe différents moyens de vous “créer” un ou des comptes Waves. Techniquement on ne “crée” pas de compte, on génère des informations associées à un compte.

Tous les comptes existent par défaut sur la blockchain à partir du moment ou ils correspondent à une adresse et paire de clés valides.

Créer un compte pour les non développeur
www.waves.exchange
Waves Desktop wallet
Waves Mobile wallet
Waves Keeper

Créer un compte pour les Développeur
ide.wavesplatform.com
Waves Signer
Librairies :
ts-lib-crypto, waves-transactions etc

Adresse du compte

Chaque compte a également une adresse unique associée et peut également créer plusieurs alias (plus facile à mémoriser) :

Adresse Mainnet :
3PPbMwqLtwBGcJrTA5whqJfY95GqnNnFMDX

Adresse Testnet/Stagenet :
3NBVqYXrapgJP9atQccdBPAgJPwHDKkh6A8
3MvujUZTtoANRzrKYKzx99Vtb9TUh6VPCA8

Alias :
christophe-waves (de 4 à 30 charactère max)

A noter qu’on différencie facilement une adresse Mainnet de Testnet car elle commence toujours par 3P pour 3N ou 3N en Testnet et Stagenet.

Balance du compte
Un compte peut stocker différents tokens, Waves ou custom tokens, tous associé à l’unique adresse du compte. Le montant de ces tokens représente la balance du compte ou Account Balance

Stockage de données

Chaque compte à également un espace de stockage associé et illimité permettant de stocker des données au format clé/valeur. Chaque clé doit être unique

Type de données stockables
Il est possible d’y écrire 4 types de données :

• String
• Boolean
• Integer
• Bytes Array

Ecrire des données
Pour écrire des données sur l’espace de stockage d’un compte il faut utiliser soit une Transaction de type Data soit une transaction de type InvokeScript.

Ecrite via Data Tx

• 100 entrées max par transaction
• 32Ko max par entrée / valeur
• 150 Ko max pour l’ensemble des entrées

Ecrite via InvokeScript Tx

• 100 entrées max par Transaction
• 5Ko par entrée / valeur
• 5 Ko max pour l’ensemble des entrées

Modification des données :

La valeur associée à chaque clé peut être réécrite en réutilisant l’une des deux transactions précédentes et en ciblant la même clé. La version actuelle de RIDE ne permet pas de supprimer d’entrées mais la version 4 à venir elle, le permettra.

Il faut visualiser cet espace de stockage comme étant l’état actuel du compte, on parle d’ailleurs généralement d’état de compte (account state) et même si on y modifie des entrées, les précédents sont toujours et de manière immuable accessibles sur la blockchain via leur identifiant de transaction.

Les types de comptes

Sur la blockchain Waves il existe 3 types de comptes.

Les comptes simple « Account » :
Représente les comptes non scriptés ou par défaut les transactions doivent être signées par la clé privé du compte émetteur

Les compte « Smart Account » :
Représente un compte auquel un script de validation (Smart Contract) a été attaché et dont les validations et signatures des différentes transactions dépendent de la logique du script associé. 1 seul script par compte. Le Script valide uniquement les transactions sortantes

Les comptes « dApp Account » :
Représente un compte auquel un script de validation peut être associé comme pour le smart account mais aussi des fonctions dites « callables « pouvant être appelée de l’extérieur avec la transaction de type InvokeScript.

Tokens

Les Tokens aussi appelés Assets représentent un actif numérique sur la blockchain, ils peuvent avoir une corrélation avec un objet réel ou être uniquement virtuel.

Il sont créés via la transaction de type Issue

Un token peut avoir une valeur économique ou non et peut être divisible ou non.

Chaque token à un identifiant unique qui correspond à l’identifiant de la transaction ayant servi à la création du dit Token.

La blockchain Waves utilise le token natif Waves qui représente le Token primaire, aussi appelé « Layer 1 Token » et tous les tokens custom créés sur la blockchain Waves représentent les token secondaire ou « Layer 2 tokens ».
Un token peut être scripté et de manière similaire au Smart Account, un token scripté, aussi appelé Smart Asset, sera chargé de valider et autoriser ou non toutes les transactions sortantes liées à ce token pour n’importe quel compte l’utilisant.

Chaque transaction nécessite un paiement en Waves appelé Transaction Fee, pris du compte de l’émetteur et servant à payer les Miners.

Les transactions

Une transaction est une action sur la blockchain initiée et signée par un compte waves.

La blockchain Waves peu valider en moyenne 100 transactions par second, les stress test de 2016 étaient allé jusqu’à 900tx/sec.

Un type de transaction spécial, le MassTransfer, permet de multiplier ce nombre par 100 en effectuant jusqu’à 100 transferts en un.

Il existe 16 types de transactions (17 on stagenet)

Chaque transaction contient un identifiant unique et un timestamp (horodatage)

Une transaction doit être signée par la clé privée de l’utilisateur avant d’être envoyée sur la blockchain (broadcast).

Elle sera ensuite vérifiée, validée et incluse dans un block attaché à la blockchain

Les types de transactions

Type 1 : Genesis transaction
Transaction unique servant à initier la blockchain

Type 2 : Transfer [Obsolète]
Transfer version 1 pour token Waves uniquement, remplacé par type 4

Type 3 : Issue transaction
Permet de créer un Token/Asset

Type 4 : Transfer transaction
Permet de transférer un Asset/token d’un compte à un autre

Type 5 : Reissue transaction
Permet de recréer des tokens si le paramètre reissue du token est à true

Type 6 : Burn transaction
Permet de détruire des tokens de manière définitive

Type 7 : Exchange transaction
Permet d’échanger des tokens entre eux

Type 8 : Lease transaction
Permet de Louer ses tokens Waves a une Node pour le Mining

Type 9 : Lease cancel transaction
Annule les tokens précédemment loués

Type 10 : Alias transaction
Permet de créer un Alias pour le compte émetteur, sont autorisé :
minuscule, nombre, point, underscore, hyphen et arobase. 4 à 30 charactères maximum

Type 11 : Mass Transfer transaction
Permet d’effectuer un transfert à plusieurs destinataires (jusqu’à 100) en une seule transaction

Type 12 : Data transaction
Permet d’écrire des données sur l’espace de stockage du compte émetteur

Type 13 : Set Script transaction
Permet d’attacher un script (Smart Contract) à un compte

Type 14 : Sponsorship transaction
Permet d’activer le principe de Sponsored Fee pour un Asset/Token

Type 15 : Set Asset Script transaction
Permet d’attacher un script (Smart Contract) à un Asset

Type 16 : Invoke Script transaction
Permet d’appeler une fonction depuis l’extérieur sur un compte dApp

Type 17 : Update Asset Info transaction [STAGENET ONLY]
Permet de modifier les informations d’un Asset/Token

Une transaction en détail

Prenons l’exemple d’une transaction de type Transfer qui une fois signée et propagée (broadcast) se présente ainsi :

SenderPublicKey : La clé public du compte ayant signé la transaction (avec sa clé privée qui elle, bien sûr reste privée)

Amount : Le montant de Token transférés

Fee : Le coût de la transaction, chaque transaction à un cout minimum fixe, il est possible de passer un montant supérieur pour accélérer la validation de la transaction.

Type : Correspond au type de transaction, chaque transaction à un type (nom entier) associé

Version : Les transactions évoluant régulièrement au même titre que la blockchain, il y a donc un système de version servant à identifier la version de la dite transaction et sa structure de données

Attachment : Il est possible d’attacher un message ou des données au format Bytes d’un maximum de 140 Bytes qui équivaut à 140 charactères

Sender : l’adresse Waves de l’émetteur

FeeAssetId : Permet de définir si on souhaite payer la transaction Fee avec un token custom au lieu de Waves. Pour que cela soit possible il faut que le token custom ai activé la fonction « Sponsored Fee «

Proof : Tableau contenant la preuve du compte ayant signé la transaction avec sa clé privée, il peut y avoir plusieurs signataires/preuves dans le cas d’un multisig par exemple

AssetId : Identifiant du token/asset à envoyé, si null (non renseigné), alors il s’agit du token Waves par défaut

Recipient : Adresse du destinataire qui recevra les tokens envoyé

FeeAsset : Idem FeeAssetId ce champ est la pour des besoins de rétrocompatibilité

Id : Identifiant unique de la transaction

Timestamp : Horodatage de la transaction

Height : Numéro / Height du block dans lequel la transaction à été incluse

Abonnez-vous à notre chaîne :
https://www.youtube.com/channel/UC2DS9ktTKWGW3NHHV2Ja3_A

Suivez nous et posez toutes vos questions sur :
Telegram : https://t.me/wavesdappsFR
Twitter : https://twitter.com/WavesDevFr
Facebook : https://www.facebook.com/wavesfr
Meetup : https://www.meetup.com/Waves-Blockchain-Developpeurs/

Wavesplatform : https://www.wavesplatform.com