Zum Inhalt

Programmier-Modell

Im Vergleich zu anderen Blockchains wird das Programmiermodell von Alephium stark von seinem sUTXO-Modell, seiner Sharding-Architektur sowie zahlreichen Innovationen und Designentscheidungen beeinflusst, die in der Ralph language und der Alphred VM getroffen wurden.

Unter dem sUTXO-Modell werden Vermögenswerte durch UTXOs verwaltet, während Vertragszustände mit dem konto-basierten Modell verwaltet werden. Dies bringt einige interessante Eigenschaften in der Programmierung mit sich:

  • Alephium unterstützt eine Bitcoin-ähnliche, zustandslose Programmierung, die ausschließlich im Rahmen von UTXOs durchgeführt wird. Es unterstützt seine eigene Version von P2SH unter Verwendung der Ralph-Sprache, die wesentlich leistungsfähiger und entwicklerfreundlicher ist als das Bitcoin-Skript.
  • Alephium unterstützt auch einen EVM-ähnlichen, zustandsbehafteten Programmieransatz, der die Manipulation des globalen Vertragszustands ermöglicht. Die Tatsache, dass Vermögenswerte jedoch separat über UTXOs verwaltet werden, beseitigt nicht nur eine Klasse von Sicherheits- und Benutzererfahrungsproblemen wie Token-Zulassungen, sondern ermöglicht auch viele Funktionen auf Sprach- und VM-Ebene, wie zum Beispiel das Asset Permission System.
  • Die Trennung der Vermögenswerte und Vertragszustände sowie die Kombination aus zustandsloser und zustandsbehafteter Programmierung eröffnen neue Möglichkeiten für den Aufbau von dApps.

Die Sharding-Architektur von Alephium bedeutet, dass dApps in einigen Fällen darauf achten müssen, dass Alephium derzeit 4 Gruppen und 16 Chains betreibt. Mit kontinuierlichen Verbesserungen der Kerninfrastruktur sowie cleverem Design von Seiten der dApps ist es möglich, ein ausgeglichenes Verhältnis zwischen Skalierbarkeit und Benutzererfahrung zu erreichen.

Das Ziel dieses Leitfadens ist es, einige der einzigartigen Programmierfunktionen von Alephium zu erklären.

TxScript

Das sUTXO-Modell ermöglicht zwei Arten von Transaktionen auf Alephium:

  • Übertragung von Vermögenswerten von Absendern an Empfänger, bei der nur UTXOs beteiligt sind.
  • Interaktionen mit Smart Contracts

Transaktionen mit Interaktionen mit Smart Contracts müssen durch ein Transaktionsskript (i.e TxScript) initiiert werden, was eine einzigartige Funktion auf Alephium ist. Es ermöglicht Entwicklern, einmalige oder wiederverwendbare Logik zu schreiben, die mehrere Vertragsaufrufe zu einer einzigen Transaktion zusammenführen kann, ohne den Aufwand und die Kosten für das Bereitstellen neuer Aggregationsverträge. TxScript ist auch flexibel und sicher, weil es die volle Leistung der Ralph-Sprache und der Alphred-VM nutzt.

Als Beispiel hier der Pseudocode eines TxScript , der zwei DEXes verwendet, um (naiv) den durchschnittlichen Wechselkurs von USD zu ALPH zu ermitteln, und dann 100 US-Dollar-wertes an ALPH an eine Wohltätigkeitsorganisation spendet:

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)
}

Bitte sehen Sie hier für ein konkreteres Beispiel, wie man mit Smart Contracts mittels TxScriptinteragiert. Um besser zu verstehen, wie Vermögenswerte von den Eingaben durch Txscript in die (festen/generierten) Ausgaben fließen, lesen Sie bitte Flow of Assets.

Asset Permission System

Das Asset Permission System ist eine der einzigartigen Funktionen von Alephium. Es macht den Fluss von Vermögenswerten auf Codeebene explizit, was sowohl Entwicklern als auch Benutzern das Vertrauen gibt, dass alle Vermögensübertragungen im Smart Contract wie beabsichtigt erfolgen.

Bitte lesen Sie Asset Permission System für eine ausführlichere Diskussion.

Contracts und UTXOs

Unter dem sUTXO-Modell werden Vermögenswerte, die regulären Adressen und Vertragsadressen gehören, beide durch UTXOs verwaltet. Der Unterschied besteht darin, dass es genau eine UTXO pro Vertragsadresse gibt, während reguläre Adressen mehrere UTXOs haben können.

Eine Transaktion unter dem UTXO-Modell hat Eingaben und Ausgaben. Eine wichtige Eigenschaft dieser Transaktionen ist, dass nachdem Vermögenswerte an eine Ausgabe übertragen wurden, die Ausgabe nicht sofort innerhalb derselben Transaktion ausgegeben werden kann.

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

TDies ist offensichtlich für einfache Vermögensübertragungen. Aber das gilt auch beim Programmieren von Smart Contracts.

Hier sind ein paar Beispiele:

  • Wenn Alice einen Kredit von einer Kreditplattform erhält, kann sie den Kredit nicht verwenden, um in derselben Transaktion ein NFT zu kaufen.
  • Wenn Bob Vermögenswerte aus einem HODL-Vertrag abhebt, kann Eve nicht innerhalb derselben Transaktion Vermögenswerte aus demselben HODL-Vertrag abheben.
  • Wenn Alice Vermögenswerte an Bob überträgt, kann Bob die Vermögenswerte nicht in derselben Transaktion zurück an Alice übertragen.

Diese Eigenschaft ist der Grund, warum Doppelteinsprünge und Reentrancy-Angriffe auf Alephium nicht möglich sind. Es macht auch risikofreien Arbitragehandel schwieriger.

Sub-contract

Ein Sub-Vertrag auf Alephium ist eine einfache und leistungsstarke Idee. Es ermöglicht die Konstruktion baumähnlicher Strukturen über eine Gruppe von verwandten Verträgen und das Durchqueren von ihnen in einer Weise, die dem Navigieren durch Domainnamen ähnelt. Im Vergleich zu regulären Karten oder Baumdatenstrukturen ermöglichen Sub-Verträge eine größere Ausdrucksfähigkeit, da jeder Knoten ein voll funktionsfähiger Vertrag ist, der in der Lage ist, Token auszugeben, komplexe Geschäftslogik auszuführen, feingranularen Zugriffskontrolle auf seinen Zustand sowie Berechtigungskontrolle auf seine Vermögenswerte, etc.

Sub-Verträge tragen auch zur langfristigen Gesundheit der Alephium-Blockchain bei, indem sie Benutzer dazu anregen, sie zu recyceln, wenn sie nicht benötigt werden. Es hält auch die Dinge auf der VM-Ebene einfach, da alles ein Vertrag ist.

Das folgende Beispiel zeigt die mint_-Funktion eines NFT-Sammlungsvertrags:

mint-Funktion
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
  )
}

Wie wir sehen können, erstellt der NFT-Sammlungsvertrag einen NFT-Subvertrag mithilfe der integrierten Funktion copyCreateSubContractWithToken. Der NFT-Subvertrag wird mit einem ausgegebenen Token erstellt, um den NFT zu repräsentieren, und der NFT-Subvertrag kann vom NFT-Sammlungsvertrag aus mithilfe der Funktion subContractId referenziert werden.

AssetScript

AssetScript ermöglicht es Alephium, das Äquivalent des P2SH -Features von Bitcoin zu implementieren. Im Wesentlichen speichert eineP2SHUTXO den Hash eines Skripts, das die Ausgabebedingung dieser UTXO festlegt. Wenn es an der Zeit ist, solche UTXOs auszugeben, muss das Skript zusammen mit den erforderlichen Argumenten bereitgestellt werden, um das Skript erfolgreich auszuführen.

Zum Beispiel wird die Unterstützung für Schnorr signature von Alephium mithilfe des folgenden AssetScript implementiert:

Rust
AssetScript Schnorr(publicKey: ByteVec) {
  pub fn unlock() -> () {
    verifyBIP340Schnorr!(txId!(), publicKey, getSegregatedSignature!())
  }
}
Wie Sie sehen können, nimmt das Skript einen öffentlichen Schlüssel als Parameter entgegen, überprüft, ob die Transaktionssignatur eine gültige Schnorr-Signatur ist, indem es die integrierte Funktion verifyBIP340Schnorr verwendet. Um eine UTXO zu verbrauchen, die unter Verwendung des Hashs des Skript-Bytecodes konstruiert wurde, muss ein öffentlicher Schlüssel bereitgestellt werden und die Transaktion muss mit einer gültigen Schnorr-Signatur von ihrem entsprechenden privaten Schlüssel signiert werden.

AssetScript ist in dem Sinne zustandslos, dass es nicht auf irgendetwas außerhalb einer gegebenen UTXO zugreifen kann, einschließlich aller Verträge.