DEV Community: Archethic

How to Build & Deploy Smart Contracts on Archethic?

Samuel Manzanera — Thu, 20 Oct 2022 16:34:46 +0000

Archethic is a new generation of decentralized and distributed ledger using the concept of TransactionChains to provide fast, scalable and secure network.

Archethic smart contracts are designed to be simple to use by its language, by its concepts and being based on the TransactionChains paradigm.

TransactionChains

Archethic relies on TransactionChain's which reduce to the most atomic form of block: the transaction.
Instead of sharing a block of the transactions with multiple other transactions, a chain is built from a wallet, a service, a smart contract.

The scalability and the speed of the transaction validation is then decoupled.

Smart Contract

Archethic leverage smart contract technology embedded into any transactions. In other words, any transaction can be a smart contract.

The smart contracts are interpreted making it easy to understand by the creators, the auditors, and the network.

They rely on 3 main concepts:

Triggers: what are the event which will execute some code
Conditions: what are the conditions met to execute some code
Actions: The code itself to generate a new transaction on the chain.

Apart from those concepts, the smart contract are easy to use thanks to a domain-specific language reducing most of the complexity and upgradable via the TransactionChains.

Let's build something

Nothing is better to explain sometimes than to show.
So, we will code and create a smart contract to demonstrate the capabilities.

For this example, we will build a crowd-sale smart contract for an ICO.

What the contract will do:

Accept some cryptocurrency transfers
Transfers some token in exchange
Close the sales after a certain duration

Conditions

Transactions

We will define some conditions for the smart contract.

condition transaction: [
    uco_transfers: size() > 0,
    timestamp: transaction.timestamp < 1665750161
]

We are defining the condition to accept only incoming transactions with some UCO transfers and before a given UNIX timestamp (the closing date of the ICO)

Inherit

Because Archethic relies on TransactionChains, after an executed code, a new transaction might be generated.
But to achieve that, the creator has to delegate its cryptographic keys to the validators, so we could generate new transactions.

However, to prevent a bad usage of the chain, we have to define some constraints making the transactions behave like expected.

condition inherit: [
   token_transfers: size() == 1
]

Disclaimer: This is just an example, it should not be taken as production ready. To harden it, you would have to check whether the destination address is within the previous transaction inputs (the UCO transfer)

By having those condition, the next transaction – while being validated – will ensure its integrity by asserting the conditions defined.

Triggers & Actions

The last remaining part is the definition of the code itself and the triggers.

actions triggered_by: transaction do
   # Get the amount of uco send to this contract
   amount_send = transaction.uco_transfers[contract.address]

   if amount_send > 0 do
      # Convert UCO to the number of tokens to credit. Each UCO worth 10 token
      token_to_credit = amount_send * 10

      # Send the new transaction
      add_token_transfer to: transaction.address, token_address: contract.address, amount: token_to_credit
  end
end

In this snippet, a new incoming transaction would trigger a code which will convert the UCO transferred into a new token transfer, based on the defined rate.

To summarize the contract creation for an ICO fits in the snippet below:

condition inherit: [
   token_transfers: size() == 1
]

condition transaction: [
    uco_transfers: size() > 0,
    timestamp: transaction.timestamp < 1665750161
]

actions triggered_by: transaction do
   # Get the amount of uco send to this contract
   amount_send = transaction.uco_transfers[contract.address]

   if amount_send > 0 do
      # Convert UCO to the number of tokens to credit. Each UCO worth 10 token
      token_to_credit = amount_send * 10

      # Send the new transaction
      add_token_transfer to: transaction.address, token_address: contract.address, amount: token_to_credit
  end
end

Let's test it

Get some funds

To be able to exchange on the network, you need some funds, you can get some funds from the faucet either using the https://mainnet.archethic.net/faucet or a local node (https://github.com/archethic-foundation/archethic-node)

Build the transaction

Archethic have an SDK to build transactions (https://github.com/archethic-foundation/libjs), which provide a page to build transaction (example/transactionBuilder)

Write the code

We are using the transaction builder to forge the transaction, by passing the chain's seed (previously funded), the code mentioned above.

Mint a token

Moreover, to use an existing token, we will mint a token in the same time.
Just specify the type of transaction as: token and defines it in the content section. (for more details, please refer to the token standard definition: https://archethic-foundation.github.io/archethic-docs/learn/token)

Authorized the nodes

Now, as explained before, we have to allow nodes to generate transaction in our behalf. Hence, we have to encrypt the chain's seed to be decrypted only by the nodes, by using the Ownerships section.

The secret being the seed, the public key being the Storage nonce public key

Contract created

After the transaction generated and sent, we have a new transaction on the chain with the tokens minted and the contract deployed

Test the interactions

We will go back to the transaction builder and generate a new transaction from another chain (funded as well), and we will send UCO to this smart contract's address (previously created)

We also have to mention the recipient address to say we want to execute code in the smart contract and not only send UCO to it.

After sending, the chain would have created a new transaction by sending the tokens.

The sender will have now in possession its token, while the contract would have got the UCO.

Conclusion

The way to create smart contract on Archethic are quite innovative to allow users to create simple code but powerful by leveraging triggers and bring confidence/security with well-defined conditions.

Apart from this, other really interesting features are supported such as easy upgrade or few triggers (date, interval, oracles, etc.)

Archethic Wallet: User vs Developer Perspective

Margarita Manzanera — Mon, 03 Oct 2022 20:48:17 +0000

What is the Archethic wallet?

Archethic has developed a fully decentralized and non-custodial cryptocurrency hot wallet that enables users to safely manage assets on Layer 1 Archethic blockchain.

No signup or KYC needed, users just control their services and access keychain, protected by different secure access methods like PIN Code, Password, YubiKey like devices and Biometrics.

What are the features of the Archethic wallet?

The user's perspective 👩🏿

Archethic Wallet has implemented the following features:

Main features

Decentralized keychain management
Multiple accounts' management
Creation of Fungible Tokens
Creation of NFTs
Support for transactions (Sending and Receiving UCO Token, Fungible Tokens and NFTs)
List of recent transactions
List of acquired tokens

Security

Security access with Password, PIN, Yubicloud OTP, Face ID, Touch ID, Uniris Biometrics (2023)
Use of 24 Words Mnemonics

Customization

Support for English and French Language
Support for multiple Currencies (view only, not meant as multiple cryptocurrencies wallet)
Multi themes (9 themes available)
UI customization

Other features

Local notifications
Access to exchanges to buy ERC20 UCO
Share address with QR Code or mobile share feature
Address book
UCO Price chart
Access latest Archethic blog articles

How is the Archethic wallet developed?

The developer's perspective 👨🏻‍💻

We developed the wallet using Flutter based on Dart language.

Flutter is an open-source mobile application development framework from Google. The main reason for its popularity is that it supports the creation of cross-platform applications. Flutter is also used to create interactive apps that run on web pages or on the desktop.

Here are some of Flutter's features*

Single code base for Android, iOS, Windows, Linux, macOS, Web, Extension: This approach simplifies and reduces the development time, cost, and maintenance is also an easy task. The Flutter-based user interface can be installed virtually on any platform. It has its own rendering engine that allows developers to keep the UI as it is while moving to another platform. As a result, application users can enjoy an excellent native-like experience on various platforms.

Open-source and made by Google: Flutter is a popular choice among developers because of the huge community support. Google designed the Flutter framework with all the security issues of modern applications in mind. One can find reliable and well-tested plugins in Flutter to mitigate security risks such as user authentication flaws, malicious code injections and data leaks.

Dart Programming: Flutter uses an easy to learn and implement programming language called Dart, which is Google's general purpose programming language.

Performance: As a cross-platform framework, Flutter offers unmatched performance compared to its competitors. Flutter compiles designs to native code. Unlike React Native, Flutter renders widgets directly from the native library rather than downloading libraries and components to the device before rendering.

*Source: https://mobiskill.fr/blog/conseils-emploi-tech/pourquoi-utiliser-flutter-en-2022/

On which platforms is the application available?

How to install the application and secure your funds?

The user's perspective 👩

You can now download our wallet on the Google Play Store in beta for the Android mobile version and via the official website of Archethic for the macOs version (https://www.archethic.net/aewallet.html).

During the onboarding process, a screen invites you to create a new wallet or to restore a wallet you already own, from a series of 24 words (seed phrase).

In the case of a new wallet, a series of 24 words (seed phrase) is proposed in English or French. This allows you to generate your private and public keys for your wallet. These words are currently the only way to recover your funds in case of loss of your mobile or uninstallation of the wallet. It is therefore essential to keep this seed phrase hidden from view and on some medium other than your devices.

⚠️ Remember that Archethic will never ask you for your 24 words series.

Once the seed phrase is saved, you can fully enjoy your wallet.

In the case of a wallet restoration, you just have to enter the 24 words of your seed phrase in the right order and the application will find your keychain and associated accounts, from the information stored on the blockchain.

The developer's perspective 👨‍💻

When the wallet is created, a seed is randomly created from a cryptographically secure random number generator provided by Dart.

static String generateSeed() {
    String result = '';
    const String chars = 'abcdef0123456789';
    final Random rng = Random.secure();
    for (int i = 0; i < 64; i++) {
      result += chars[rng.nextInt(chars.length)];
    }
    return result.toUpperCase();
  }

In order to make the seed more accessible, BIP39 is used and aims to provide a method of simplifying the reading of the seed using a series of mnemonic words. BIP39 takes random words (usually from the English language, although they can be from another language) and creates a long phrase with them, usually 12 to 24 words. In the case of the Archethic wallet, we use 24 words because the higher the number of words, the greater the entropy and security attributable to the resulting sentence. These words are chosen from a dictionary of 2048 words. The flutter library bip39_mnemonic is thus used with English and French dictionaries.

In the case of wallet restoration, the library bip39_mnemonic allows to find the seed from the seed phrase.

How to secure the application?

The user's perspective 👨🏾‍🦱

Access to the application and interactions with the blockchain are secured so that certain actions are not done beyond the user's control.

Following are the ways to access:

by PIN code, comprising of 6 digits, with the possibility to mix the numbers of the keyboard to reduce the risks of access to your code by observation,
by password,
by using a YubiKey, it is an electronic authentication device to secure your access. Whether you are using NFC with your mobile or USB on your desktop, you can identify yourself with this key,
by the touch ID or face ID system, depends on the capabilities of your device.

The developer's perspective 👩🏽‍💻

In the case of PIN and password, authentication information is stored locally (see "What data is stored in my device?").
In the case of touch ID or Face ID, the Flutter Local Auth library provides the means to authenticate on devices supporting fingerprint or facial recognition authentication.

Finally, for OTP via Yubicloud: Yubico OTP is a simple yet strong authentication mechanism that is supported by all YubiKeys out of the box. Yubico OTP can be used as the second factor in a 2-factor authentication scheme or on its own, providing 1-factor authentication. YubiCloud is the name of Yubico’s web service for verifying OTPs. Before using YubiCloud, you need to get an API key from here - it is quick, free and helps us in preventing misuse of YubiCloud.
I developed a Yubico dart library for Dart/Flutter to interact with Yubicloud in my personal GitHub repository.

What data is stored in my device?

The user's perspective 👨

We store a set of information so that the application is functional in both online and offline mode.

The first group of information represents the globally available user preferences:

First Launch: Allows to know if this is the first launch of the application in order to clear the keystore for iOS. Indeed, iOS key store is persistent, so if this is first launch then we will clear the keystore.
Authentification Method: Allows to know which authentication mode is used (PIN, password, YubiKey, biometrics).
Current Currency: Allows you to know what currency is used in the application.
Current Language: Allows you to know which language is used in the application.
Current Primary Setting: Allows to know if the currency displayed in priority is Fiat or Crypto.
Current Network: Allows to know if the wallet is connected to mainnet, testnet or to a local node whose endpoint is recorded in the following information.
Current Network Endpoint: Allows to know the address of the local node.
Current Theme: Allows to know which theme is used in the application.
Lock: Allows to know if it is necessary to authenticate at the launching of the application.
Lock Timeout: Allows to know after how long the application requires authentication at its launch if the user has left the application open to browse for another one for example.
Pin Pad Shuffle: Allows you to determine whether the PIN code keyboard should be shuffled when entering.
Show Balances: Allows you to determine if the financial information should be displayed.
Show Blog: Allows you to know which blog articles should be displayed.
Show Price Chart: Allows you to determine whether the graph and indicators of the UCO price chart should be displayed.
Active Vibrations: Allows to know if at each action, a small vibration is emitted on the mobiles.
Active Notifications: Allows to know if the notifications of reception of UCO are active or not.
Language Seed: Allows to know if the seed phrase is composed of French or English words.

The second group of information represents the sensitive elements related to security:

Seed: Allows to store the wallet seed needed to perform transactions on the Archethic blockchain.
PIN: Allows to store the PIN code in case this authentication method has been chosen.
Password: Allows to keep the password in case this authentication method has been chosen.
Yubicloud ID and API Key: Allows to keep the authentication information for the management of the OTP with the YubiKey in case this authentication method has been chosen.

This information is stored securely.

And finally, a secure 256-bit (32 bytes) encryption key to secure data on the disk.
⚠️ Remember that Archethic will never pass on your data to a third party or use your data in any other way than that offered by the application.

The privacy policy is available on our website.

The developer's perspective 👨🏻‍💻

In the case of user preference data, we made the choice to store it in a local database Hive rather than the Flutter object SharedPreferences for performance reasons. All the information is available in this medium article.

These data are stored in clear text because they are not sensitive.

On the other hand, the information related to security management must be protected. Here again, Hive is used but the stored values are encrypted. Hive provides a helper function to generate a secure encryption key using the Fortuna random number generator.
The key is stored base 64 encoded in a secure space via the FlutterSecureStorage library.

static Future<Vault> getInstance() async {
    try {
      const FlutterSecureStorage secureStorage = FlutterSecureStorage();
      final Uint8List encryptionKey;
      String? secureKey =
          await secureStorage.read(key: 'archethic_wallet_secure_key');
      if (secureKey == null || secureKey.isEmpty) {
        final List<int> key = Hive.generateSecureKey();
        encryptionKey = Uint8List.fromList(key);
        secureKey = base64UrlEncode(key);
        await secureStorage.write(
            key: 'archethic_wallet_secure_key', value: secureKey);
      } else {
        encryptionKey = base64Url.decode(secureKey);
      }
      final Box<dynamic> encryptedBox = await Hive.openBox<dynamic>(_vaultBox,
          encryptionCipher: HiveAesCipher(encryptionKey));
      return Vault._(encryptedBox);
    } catch (e) {
      throw Exception();
    }
  }

How does the wallet interact with the Archethic blockchain?

The developer's perspective 👩‍💻

Based on the Archethic JS SDK, a SDK has been developed in dart and is maintained by the Archethic teams in order to offer internal or community-developed Flutter DApps to interact with the Archethic Blockchain.

This open-source SDK "archethic_lib_dart", available on GitHub, can be added as dependencies in Dart or Flutter projects via the Flutter libraries and packages sharing site Pub.dev.

The available functions are:

Cryptographic functions,
Transaction building,
Remote endpoint calls,
Keychain / Wallet management,
CoinGecko functions.

All the documentation is available in the readme of the library.

Wallet timeline

Some elements of the SDK and wallet history are shown here:

The author's perspective 👷

Until now, the Archethic community has always been involved in the development of the wallet to improve both the technical aspects and the user experience. The wallet has the vocation to be accessible to all to simplify and secure the uses.

You can follow or contribute to the development of the application via the dedicated repository on GitHub or via the official page of the application.

Author: Sylvain Séramy, Head of Front-End Department at Archethic Technologies

Self Healing Blockchains

Margarita Manzanera — Mon, 19 Sep 2022 19:39:50 +0000

The world is eagerly waiting for a next-generation, high-performance, permission-less blockchain and this blockchain should be able to industrially scale all decentralized applications. So far, the world/crypto community has witnessed:

P2P blockchain networks that use all the peers to validate transactions, do computation and storage. For example, Bitcoin, Ethereum … (Traditional Blockchains)
P2P blockchain networks that shard transactions, computation, and storage. For example, Ethereum 2.0, Zilliqa … (Sharding Blockchains)

The sharding mechanism in blockchain gives hope for an unlimited and sustainable scalability of blockchains. But many people in the blockchain space strongly believe that the scalability of the blockchain networks or the sharding mechanism has reached a tipping point. Not true! How?
In this article, we will discuss the problems that plague sharding mechanisms in permission-less blockchain. And, how the self-healing mechanism is the only solution to this.

In the blockchain world, why do we need sharding?

Currently, the internet is used in Payments, IoT, smart city, robotics, web search, streaming videos, e-commerce, autonomous vehicles, etc. Hence, the internet generates

over billion transactions per second (Transaction)
over sextillion calculations per second (Computation)
over 2.5 quintillion bytes of data per second (Storage)

This work needs to be harmoniously split among all the peers in a P2P network. This splitting of work is called the Sharding Technology. Sharding can be applied to transaction, computation, and storage.

Problems that plague Sharding Mechanism

A permission-less P2P network is unpredictable and to compensate for this unpredictability, various blockchain protocols fix the number of validations and the number of storage copies to a constant that is derived from a mathematical computation based on certain assumptions. This limits the scalability of blockchains since the system will either over-compensate and limit scale or under-compensate and risk security/integrity.

What if the P2P network can be predicted? Can the number of validation and number of storage peers be flexible depending on the chaoticity of the P2P network? That is to say, if the P2P network behaves ideally then only 1 validation and storage copy is needed and if the peers in the P2P network behave maliciously or deviate from the ideal nature, then the number of validation and storage copies will increase proportionally.

Problems faced by peers/shard in the P2P network:

Internet connection problems, electricity cuts, data loss, many more …
Joining and leaving the network all the time throughout the globe.
Data availability and data consistency problems
If a peer/shard goes offline, the data belonging to that shard is lost forever.
Peers/shard can turn malicious anytime

The culprit here is the unpredictability of the P2P network! This unpredictability of P2P network decreases the performance of validation, computation, and storage.

Self-Healing Blockchain

Due to the uncertainty in the P2P network, the self-healing mechanism is introduced!

Case 1: (Traditional Blockchains) where all the N nodes in the network validate/compute/store all the transactions in the network. (N)

Case 2: (Ideal P2P) Consider an ideal P2P blockchain network where all the peers in the network are available 24×7, with good internet, bandwidth, electricity supply, etc. and are good peers (not malicious). Then any transaction/computation/storage that arrives to the network can be validated/computed/stored by 1 peer. (1)

Case 3:(Sharded Blockchains) But the real P2P blockchain network is not so and hence a mathematical formula is derived based on the maximum possible deviation from the ideal P2P blockchain network and certain assumptions to set a fixed number like 22–600 peers to validate/compute/store depending on the blockchain protocol. (N/x)

Case 4: (Self-Healing Blockchains) Cases 1, 2 and 3 are extreme scenarios as shown in the graph! The number of transactions/computation/storage should depend on the amount of deviation from the ideal state (with adequate safety margin). (N/x(c)) where c stands for chaoticity of the network.

Chaoticity © of the network is a function of (internet bandwidth, electricity, data availability, data consistency, no of nodes joining or leaving). Any change in the function compared to the ideal state (whether positive or negative), the counter measures are deployed accordingly by the P2P network.

Hence the network automatically heals if there is any stress in the network.

Analogy to self-healing blockchains

Let us take the example of Paris metro, where depending on the traffic of people, the metro trains change the timings, frequency, the number of compartments, and speed!

Traditional: There will be a maximum number of metro trains, with maximum frequency, with maximum number of compartments and with maximum speed of the metro train all the time. (Lot of energy is wasted)
Ideal: There will be a minimum number of metro trains, with minimum frequency, with minimum number of compartments and with minimum speed of the metro train all the time. (Takes a lot of time for people to commute)
Sharded: The number of metro train, the frequency, number of compartments, speed of the metro train will be less than the maximum, but the numbers are fixed no matter the number of people who want to use the metro.
Self-Healing: Depending on the no of people, peak hours from 7AM - 9AM and 4PM - 7PM, number of metros available, etc. … The number of metro trains, the frequency, number of compartments, speed of the metro train change accordingly and are flexible for a harmonious output.

To Conclude

Self-healing blockchains are designed in such a way that they can survive for decades, if not centuries. The scalability achieved by these types of blockchains are close to centralized systems yet maintaining true decentralization. Since there is high scalability, any centralized application can be built on the self-healing blockchains.

Applying artificial intelligence to the time series (internet bandwidth, electricity, data availability, data consistency, data loss, number of nodes joining/leaving, etc.) could further improve the self-healing blockchains making them faster and able to predict an event before it happens and hence deploying countermeasures to handle any event before even happening!

There are multiple blockchain protocols leading the self-healing blockchain space, one of them is Archethic, a blockchain startup based in Paris, France with multiple patents registered on this.

"Self-healing blockchains are the only way that can lead to a true decentralized world within a decade"

Author: Akshay Reddy, Chief Product Officer at Uniris