Aller au contenu

Modèle de programmation

Comparé à d'autres blockchains, le modèle de programmation d'Alephium est fortement influencé par son modèle sUTXO son architecture de sharding, ainsi que par de nombreuses innovations et décisions de conception réalisées dans le langage Ralph et la machine virtuelle Alphred.

Sous le modèle sUTXO les actifs sont gérés par des UTXO tandis que les états des contrats sont gérés selon un modèle basé sur les comptes. Cela apporte quelques propriétés intéressantes en matière de programmation:

  • Alephium prend en charge une programmation sans état similaire à celle de Bitcoin, entièrement réalisée dans le cadre des UTXO. Il prend en charge sa propre version de P2SHen utilisant le langage Ralph, qui est beaucoup plus puissant et convivial pour les développeurs que le script Bitcoin.
  • Alephium prend également en charge une programmation étatique de style EVM qui permet la manipulation de l'état global des contrats. Cependant, le fait que les actifs soient gérés séparément à l'aide des UTXO non seulement élimine une classe de problèmes de sécurité et d'UX tels que les approbations de jetons, mais rend également possibles de nombreuses fonctionnalités au niveau du langage et de la VM, comme le Asset Permission System.
  • La séparation des actifs et des états de contrat, ainsi que la combinaison de la programmation sans état et de la programmation étatique, ouvrent de nouvelles possibilités pour la construction de dApps.

L'architecture de sharding d'Alephium signifie que les dApps, dans certains cas, doivent être conscientes du fait qu'Alephium fonctionne actuellement avec 4 groupes et 16 chaînes. Avec les améliorations continues de l'infrastructure de base ainsi que la conception astucieuse du côté des dApps, il est possible d'atteindre un bon équilibre entre la scalabilité et l'expérience utilisateur.

Le but de ce guide est d'expliquer certaines des fonctionnalités de programmation uniques d'Alephium.

TxScript

Le modèle sUTXO permet deux types de transactions sur Alephium:

  • Transfert d'actifs des expéditeurs aux destinataires où seuls les UTXO sont impliqués.
  • Interactions avec des contrats intelligents

Les transactions avec interactions de contrats intelligents doivent être initiées par un script de transaction (c'est-à-dire unTxScript), ce qui est une fonctionnalité unique sur Alephium. Cela permet aux développeurs d'écrire une logique ponctuelle ou réutilisable qui peut composer plusieurs appels de contrat dans une seule transaction, sans les frais et les coûts de déploiement de nouveaux contrats d'agrégation. TxScript est également flexible et sécurisé car il tire parti de toute la puissance du langage Ralph et de la machine virtuelle Alphred.

À titre d'exemple, voici le pseudo-code d'un TxScript qui utilise deux DEX (échanges décentralisés) pour (de manière naïve) déterminer le taux de change moyen du USD en ALPH, puis faire don de 100 $ d'ALPH à une œuvre de bienfaisance:

Rust
TxScript Donate(dex1: Dex, dex2: Dex, charity: Charity) {
  let rate1  = dex1.exchangeRateOfUSDToALPH()
  let rate2  = dex2.exchangeRateOfUSDToALPH()
  let amount = 100 / ((rate1 + rate2) / 2)
  charity.donate{donor -> ALPH: amount}(amount)
}

Veuillez consulter ici pour un exemple plus concret de l'interaction avec des contrats intelligents en utilisant TxScript. Pour mieux comprendre comment les actifs circulent des entrées à travers Txscript dans les sorties (fixes/générées), veuillez lire Flux des Actifs.

Système de Permission des Actifs

Le système de permission des actifs est l'une des fonctionnalités uniques d'Alephium. Il rend le flux des actifs explicite au niveau du code, donnant aux développeurs et aux utilisateurs la confiance que tous les transferts d'actifs dans le contrat intelligent se déroulent comme prévu.

Veuillez lire Système de Permission des Actifs pour une discussion plus approfondie.

Contrats et UTXOs

Sous le modèle sUTXO les actifs détenus par des adresses régulières et des adresses de contrat sont tous deux gérés par des UTXO. La différence est qu'il y a exactement un UTXO par adresse de contrat alors que les adresses régulières peuvent avoir plusieurs UTXO.

Une transaction sous le modèle UTXO a des entrées et des sorties. Une propriété importante de ces transactions est que, après que les actifs ont été transférés à une sortie, la sortie ne peut pas être dépensée immédiatement dans la même transaction.

Text Only
               ----------------
               |              |
   input       |              |   output
=============> | Transaction  | ===========>
               |              | 
               |              | 
               ----------------

Cela est assez évident pour un simple transfert d'actifs. Mais cela est également vrai lors de la programmation de contrats intelligents. Voici quelques exemples :

  • Si Alice reçoit un prêt d'une plateforme de prêt, elle ne peut pas utiliser le prêt pour acheter un NFT dans la même transaction.
  • Si Bob retire des actifs d'un contrat HODL, Eve ne peut pas retirer des actifs du même contrat HODL dans la même transaction.
  • Si Alice transfère des actifs à Bob, Bob ne peut pas transférer les actifs de nouveau à Alice dans la même transaction.

Cette propriété est la raison pour laquelle les problèmes de double dépense et les attaques de réentrance ne sont pas possibles sur Alephium. Cela rend également l'arbitrage sans risque plus difficile.

Le sous-contrat

Le sous-contrat sur Alephium est une idée simple et puissante. Il permet de construire des structures arborescentes à travers un groupe de contrats liés et de les traverser de manière analogue à la navigation à travers les noms de domaine. Comparé aux cartes ou structures de données arborescentes classiques, les sous-contrats permettent une expressivité accrue puisque chaque nœud est un contrat entièrement fonctionnel capable d'émettre des jetons, d'exécuter une logique métier sophistiquée, d'avoir un contrôle d'accès fin à son état ainsi qu'un contrôle des permissions sur ses actifs, etc.

Les sous-contrats contribuent également à la santé à long terme de la blockchain Alephium en incitant les utilisateurs à les recycler lorsqu'ils ne sont pas nécessaires. Cela simplifie également les choses au niveau de la VM puisque tout est un contrat.

L'exemple suivant montre la fonction mint_ d'un contrat de collection de NFT:

Rust
@using(preapprovedAssets = true)
fn mint_(minter: Address, index: U256) -> ByteVec {
  let (encodeImmutableFields, encodeMutableFields) = NFT.encodeFields!(getNFTUri(index), selfContractId!(), index)
  return copyCreateSubContractWithToken!{minter -> ALPH: 1 alph}(
      toByteVec!(index),
      nftTemplateId,
      encodeImmutableFields,
      encodeMutableFields,
      1,
      minter
  )
}

Comme nous pouvons le voir, le contrat de collection de NFT crée un sous-contrat de NFT en utilisant la fonction intégrée copyCreateSubContractWithToken Le sous-contrat de NFT est créé avec un jeton émis pour représenter le NFT, et le sous-contrat de NFT peut être référencé depuis le contrat de collection de NFT en utilisant la fonction subContractId.

AssetScript

AssetScript permet à Alephium d'implémenter l'équivalent de la fonctionnalité P2SH de Bitcoin. En résumé, un UTXO P2SH stocke le hachage d'un script qui spécifie la condition de dépense de cet UTXO. Lorsqu'il est temps de dépenser de tels UTXOs, le script doit être fourni avec les arguments requis pour exécuter avec succès le script.

Par exemple, le support de la signature Schnorr d'Alephium est implémenté à l'aide du AssetScript suivant:

Rust
AssetScript Schnorr(publicKey: ByteVec) {
  pub fn unlock() -> () {
    verifyBIP340Schnorr!(txId!(), publicKey, getSegregatedSignature!())
  }
}
Comme vous pouvez le voir, le script prend en paramètre une clé publique, vérifie si la signature de la transaction est une signature Schnorr valide en utilisant la fonction intégrée verifyBIP340Schnorr. Pour dépenser un UTXO construit en utilisant le hachage du bytecode du script, une clé publique doit être fournie et la transaction doit être signée avec une signature Schnorr valide par sa clé privée correspondante.

AssetScript est sans état dans le sens où il ne peut pas accéder à quoi que ce soit en dehors d'un UTXO donné, y compris les contrats.