一文帶你深入淺出Arc-20和Brc-20協議

中級2/1/2024, 6:08:55 AM
本文從技術角度出髮深入兩個協議的細節以及優劣勢。

引言

在近期Arc-20協議出現後又使銘文市場大火了一把,本文將從技術角度出髮深入兩個協議的細節以及優劣勢。

爲什麽會出現Brc-20 和 Arc-20?

比特幣最初被設計爲一種安全、穩定且可靠的去中心化數字貨幣。然而,由於其技術架構和腳本語言相對不如以太坊靈活,因此比特幣併不適合直接運行智能合約。

盡管如此,開髮者的創新思想和大膽嘗試爲比特幣生態帶來了繁榮,其中一個典型例子就是Brc-20協議。該協議核心思想是實驗性的代幣形式,以meme爲中心。任何人都可以根據先到先得的原則,在比特幣鏈上直接鑄造這些代幣,而無需依賴智能合約。Brc-20代幣的關鍵特徵是其分散化性質,摒棄了私人髮售、預售以及解鎖或質押等機製。這確保了參與的真正去中心話。

在這一背景下,Arc-20協議再次引髮了對銘文的濃厚興趣。

什麽是UTXO模型?

Brc-20協議和Arc-20協議都基於Btc鏈,因此在正式介紹Arc-20協議和Brc-20協議之前,我們需要簡單的認識一下UTXO(unspent transaction output)

當我們談論比特幣時,UTXO(未花費的交易輸出)模型是一種重要的設計概念。它是比特幣使用的一種賬戶模型,與傳統的賬戶餘額模型(如銀行賬戶)有所不衕。

在UTXO模型中,每個比特幣交易都創建了一繫列未花費的輸出,每個輸出代錶了一定數量的比特幣。這些未花費的輸出實際上是未使用的數字貨幣單位,類似於紙幣或硬幣。當你收到比特幣時,實際上是有人創建了一個新的未花費的輸出,該輸出與你的比特幣地址相關聯。這個輸出就是UTXO。

讓我們用一個簡單的例子來解釋UTXO模型:

如果你有兩筆交易,一筆收到了0.7 BTC,另一筆收到了0.5 BTC,你將擁有兩個 UTXO,一個價值0.7 BTC,一個價值0.5 BTC。當你想要支付1 BTC 時,你不能簡單地使用一個 UTXO,而是需要將兩個 UTXO 合併爲一個新的 UTXO(總額爲1.2 BTC),然後將1 BTC 髮送給收款方,剩餘的0.2 BTC 作爲找零返回給你自己。但找零實際情況可能會低於0.2BTC,因爲用戶需要給礦工一筆手續費以確保交易的正常運行。

Brc-20協議技術實現

BRC-20是一個實驗性標準,演示了通過利用序數理論和銘文,在比特幣的第一層(layer 1)上創建可互換代幣的可能性。Ordinals協議(第一個按照該協議標準所鑄造的代幣)允許內容,包括文本、圖像或視頻,被銘記在比特幣最小單位 — — 聰(Satoshi)上,從而創造出獨特的數字資産。

序數理論是在BTC網絡上實現銘文的關鍵。

每個聰本質上是一樣的,Ordinals通過敘述理論製定了一套聰的排序協議,這個排序基於聰的挖出和他們交易輸入和輸出的順序

序數有幾種不衕的錶示方法:

  • 整數錶示法:2099994106992659 是根據聰挖掘的順序分配的序數。
  • 小數錶示法:3891094.16797 第一個數字是聰被挖掘的區塊高度,第二個數字是聰在區塊內的偏移量。
  • 度數錶示法:3°111094′214″16797‴。稍後我們會講到這個。
  • 百分位錶示法:99.99971949060254%。錶示聰在比特幣供應中的位置,用百分比錶示。

度數錶達法中包含四個部分:A°B′C″D‴,併且A,B,C,D代錶著不衕的含義:

  • A:周期,從0開始編號。 (周期循環:每六次減半就會髮生一些神奇的事情:減半和難度調整會衕時髮生,這就是所謂的相合,相合之間的時間周期是一個周期。大約每24年就會髮生一次相合,第一次相合應該會髮生在2032年的某個時候。)
  • 減半時代內的區塊索引。
  • 難度調整期間的區塊索引。
  • 區塊內聰的索引。

敘述理論通過度數錶達法來確定一個聰的順序,併且通過順序來給每個聰定義不衕的稀有程度,從而實現每個聰的獨一無二

  • 普通:區塊中的任意非第一個聰。
  • 罕見:每個區塊的第一個聰。
  • 稀有:每個難度調整周期的第一個聰。
  • 史詩:每個減半時代的第一個聰。
  • 傳説:每個周期的第一個聰。
  • 神話:創世區塊中的第一個聰。

舉例説明,比如現有一個度數錶達爲 1°1′0″0‴ ,其中

  • 1°:代錶第二個循環周期
  • 1′:代錶不是減半周期的第一個區塊
  • 0″:代錶難度調整的第一個區塊
  • 0‴ :代錶區塊的第一顆聰

通過上麵的稀有度定義,這個聰被定義爲罕見的聰。

大緻的流程如下所緻:

在Ordinals中是如何通過代碼實現的呢?

py# 計算給定高度的塊的敘述(獎勵)

def subsidy(height):

return 50 * 100_000_000 >> height // 210_000

這個函數用於計算給定高度的比特幣塊的獎勵,其中 50 * 100_000_000 是比特幣的起始獎勵,>> 是右移位運算符,相當於除以 2 的整數除法。這個函數返回一個整數,錶示在給定高度的塊的獎勵數量。

計算給定高度的塊的第一個獎勵的序數

def first_ordinal(height):

start = 0

for h in range(height):

start += subsidy(h)

return start

這個函數計算在給定高度的塊的第一個獎勵的序數。通過迭代高度併纍加每個塊的獎勵,計算從第一個塊到給定高度的總獎勵數量,從而得到第一個獎勵的序數。

爲給定塊分配序數

def assign_ordinals(block):

first = first_ordinal(block.height)

last = first + subsidy(block.height)

coinbase_ordinals = list(range(first, last))

爲給定塊分配序數

def assign_ordinals(block):

first = first_ordinal(block.height)

last = first + subsidy(block.height)

coinbase_ordinals = list(range(first, last))

for transaction in block.transactions[1:]:

ordinals = []

for input in transaction.inputs:

 ordinals.extend(input.ordinals)

for output in transaction.outputs:

 output.ordinals = ordinals[:output.value]

 del ordinals[:output.value]

coinbase_ordinals.extend(ordinals)

for output in block.transactions[0].outputs:

output.ordinals = coinbase_ordinals[:output.value]

del coinbase_ordinals[:output.value]

這個函數用於爲給定的比特幣塊分配序數。它首先計算塊的第一個和最後一個獎勵的序數範圍。接下來,它迭代塊中的每個交易,爲每個輸出分配序數。最後,爲交易的輸出分配序數,以確保整個塊中的所有聰都有唯一的序數。

簡而言之,通過序數理論,oridinals將本質上每個相衕的聰(Satoshi) 通過加工變得獨一無二起來,併且通過規則爲每一個聰定義稀有熟悉, 實現收藏屬性或者適製定玩法的規則。

使用場景

  • 趣味性:獨特有趣的協議將會爲比特幣生態再次帶來繁榮。
  • 資産髮行:brc-20代幣可以作爲資産、權益或其他可互換實體的數字錶示。這些可以是穩定幣、實用代幣,也可以是基於meme的代幣。
  • dApp集成:開髮人員可以將brc-20代幣集成到利用比特幣網絡的去中心化應用程序中。它們的應用範圍從産生收益和抵押貸款到權益質押等多方麵。
  • 資産代幣化:brc-20標準促進了任何資産或權益的代幣化,打開了許多可能性,例如基於代幣的社區或DAO投票。
  • 交換機製:brc-20代幣可以通過各種平颱在比特幣網絡的第一層進行便捷的交換和交易。雖然它們目前可以通過訂單簿進行訪問,但將它們整合到流動性池交換中的計畫已經在近期出現在大衆視野中

Arc-20技術實現

Atomicals 協議是一個簡單而靈活的協議,用於在未花費的交易輸出(UTXO)區塊鏈(如比特幣)上鑄造、轉移和更新數字對象(傳統上稱爲非衕質化代幣)。一個 Atomical(或稱爲 “atom”) 是一種管理數字對象的創建、轉移和更新的方式 — — 本質上是根據一些簡單規則定義的數字所有權鏈。

Arc-20採用了染色幣模型,也就是説一個Arc-20 token都必鬚有一個聰支持,而非像Brc-20通過排序進行區分。由於Arc-20 代幣完全基於聰,使得他可以像Btc一樣進行拆分和合併(也就是文章開頭提及的UTXO),併且可以直接通過比特幣網絡進行轉帳。

舉例説明,通過Atomicals 協議,我們將指定的100個聰定義爲100張“電影票”,用戶可以在支持Atomicals協議的電影院,拿這100個聰中的一個來支付,充當電影票的職能

但是礦工和比特幣網絡併不能知道哪個UTXO經過了”Atomicals”化,從而可能誤把Arc-20代幣當成礦工費用,爲了解決這一問題,Artomicals通過指令操作,將每一個Arc-20代幣都作爲交易的第一個輸出來避免代幣的誤銷毀。

使用場景

  • 數字收藏品、媒體和藝術
  • 數字身份、身份驗證和令牌門控內容。
  • Web托管和文件存儲
  • 點對點交換和原子交換
  • 數字命名空間分配
  • 虛擬土地和所有權註冊
  • 游戲中的動態對象和狀態
  • 社交媒體個人資料、帖子和社區
  • 任何安全性和去中心化是關鍵問題的地方。具備軍用級別的安全性和驗證要求。

Brc-20 vs Arc-20

接下來,我們將分析比較兩個協議的異衕。

Brc-20

協議大緻分爲三步

  • 部署者需要將代幣的相關信息按照協議格式寫入至BTC鏈上

{

“p”: “brc-20”,

“op”: “deploy”,

“tick”: “ordi”,

“max”: “21000000”,

“lim”: “1000”

}

  • 索引器讀取鏈上代幣相關數據
  • 鏈下賬本記録代幣的相關餘額,處理轉賬

由於部署者在部署代幣時,代幣信息本身無法被BTC所識別,因此需要一個索引器(indexer)來穫取鏈上相關數據併通過該數據在鏈下創建一個賬本來記録相關歷史以及處理相關操作併進行數據更新。

鏈下索引器需要精準的捕穫每次一代幣操作併更新線下賬本。但衕區塊鏈一樣,隨著交易的增多,節點存儲的數據將會越來越大,如何保證賬本的完整性以及在龐大的數據量中找到需要更改的信息,將會成爲brc-20的挑戰

Arc-20

衕樣的,Arc-20協議在部署代幣時也需要在BTC鏈上根據格式記録相關信息

program.command(‘init-dft’)

.description(‘Initialize fungible token (FT) atomical in decentralized issuance mode’)

.argument(‘<ticker>’, ‘string’)

.argument(‘<mint_amount>’, ‘number’)

.argument(‘<max_mints>’, ‘number’)

.argument(‘<mint_height>’, ‘number’)

.argument(‘<file>’, ‘string’)

.option(‘—rbf’, ‘Whether to enable RBF for transactions.’)

.option(‘—funding <string>’, ‘Use wallet alias wif key to be used for funding and change’)

.option(‘—satsbyte <number>’, ‘Satoshis per byte in fees’, ‘15’)

.option(‘—mintbitworkc <string>’, ‘Whether to require any bitwork proof of work to mint. Applies to the commit transaction.’)

.option(‘—mintbitworkr <string>’, ‘Whether to require any bitwork proof of work to mint. Applies to the reveal transaction.’)

.option(‘—bitworkc <string>’, ‘Whether to put any bitwork proof of work into the token mint. Applies to the commit transaction.’)

.option(‘—bitworkr <string>’, ‘Whether to put any bitwork proof of work into the token mint. Applies to the reveal transaction.’)

.option(‘—parent <string>’, ‘Whether to require a parent atomical to be spent along with the mint.’)

.option(‘—parentowner <string>’, ‘Wallet owner of the parent to spend along with the mint.’)

.option(‘—disablechalk’, ‘Whether to disable the real-time chalked logging of each hash for Bitwork mining. Improvements mining performance to set this flag’)

.action(async (ticker, mintAmount, maxMints, mintHeight, file, options) => {

…..

}

atomicals-js cli源碼中可以找到初始化一個代幣的相關指令,必鬚要在鏈上記録的參數有:

ticker: 代幣名稱

mint_amount: mint總量

max_mints: 單次mint數量

mint_height: 指定開始mint的區塊高度

file: 相關元數據

但與Brc20不衕的是, Arc20採用了染色幣模型,在代幣相關信息録入BTC鏈上後,該協議將會把代幣與Sats做錨定:1 token = 1 sat。

衕時,染色幣模型的使用使得用戶在進行交易時可以直接通過BTC網絡實現而非鏈下賬本,因爲代幣餘額與UTXO中的聰保持一緻,代幣的相關變化都可以在鏈上直觀的反映。索引器在Arc-20中隻是用來讀取代幣在鏈上的相關部署信息,併且驗證哪些是符合Arc-20協議的代幣。

總結

Brc-20的設計結構更依賴與鏈下賬本,而Arc-20更符合Btc的相關特性,併且相較於Brc-20會更去中心化。但衕時,染色幣模型使得Arc-20無法完成meme幣的髮售,因爲meme幣往往有很高的代幣總數,而1 token = 1 sat這一特性使得在髮售meme幣時需要消耗大量Btc

聲明:

  1. 本文轉載自[medium],著作權歸屬原作者[@YanAemons],如對轉載有異議,請聯繫Gate Learn團隊,團隊會根據相關流程盡速處理。
  2. 免責聲明:本文所錶達的觀點和意見僅代錶作者個人觀點,不構成任何投資建議。
  3. 文章其他語言版本由Gate Learn團隊翻譯, 在未提及Gate.io的情況下不得覆製、傳播或抄襲經翻譯文章。

一文帶你深入淺出Arc-20和Brc-20協議

中級2/1/2024, 6:08:55 AM
本文從技術角度出髮深入兩個協議的細節以及優劣勢。

引言

在近期Arc-20協議出現後又使銘文市場大火了一把,本文將從技術角度出髮深入兩個協議的細節以及優劣勢。

爲什麽會出現Brc-20 和 Arc-20?

比特幣最初被設計爲一種安全、穩定且可靠的去中心化數字貨幣。然而,由於其技術架構和腳本語言相對不如以太坊靈活,因此比特幣併不適合直接運行智能合約。

盡管如此,開髮者的創新思想和大膽嘗試爲比特幣生態帶來了繁榮,其中一個典型例子就是Brc-20協議。該協議核心思想是實驗性的代幣形式,以meme爲中心。任何人都可以根據先到先得的原則,在比特幣鏈上直接鑄造這些代幣,而無需依賴智能合約。Brc-20代幣的關鍵特徵是其分散化性質,摒棄了私人髮售、預售以及解鎖或質押等機製。這確保了參與的真正去中心話。

在這一背景下,Arc-20協議再次引髮了對銘文的濃厚興趣。

什麽是UTXO模型?

Brc-20協議和Arc-20協議都基於Btc鏈,因此在正式介紹Arc-20協議和Brc-20協議之前,我們需要簡單的認識一下UTXO(unspent transaction output)

當我們談論比特幣時,UTXO(未花費的交易輸出)模型是一種重要的設計概念。它是比特幣使用的一種賬戶模型,與傳統的賬戶餘額模型(如銀行賬戶)有所不衕。

在UTXO模型中,每個比特幣交易都創建了一繫列未花費的輸出,每個輸出代錶了一定數量的比特幣。這些未花費的輸出實際上是未使用的數字貨幣單位,類似於紙幣或硬幣。當你收到比特幣時,實際上是有人創建了一個新的未花費的輸出,該輸出與你的比特幣地址相關聯。這個輸出就是UTXO。

讓我們用一個簡單的例子來解釋UTXO模型:

如果你有兩筆交易,一筆收到了0.7 BTC,另一筆收到了0.5 BTC,你將擁有兩個 UTXO,一個價值0.7 BTC,一個價值0.5 BTC。當你想要支付1 BTC 時,你不能簡單地使用一個 UTXO,而是需要將兩個 UTXO 合併爲一個新的 UTXO(總額爲1.2 BTC),然後將1 BTC 髮送給收款方,剩餘的0.2 BTC 作爲找零返回給你自己。但找零實際情況可能會低於0.2BTC,因爲用戶需要給礦工一筆手續費以確保交易的正常運行。

Brc-20協議技術實現

BRC-20是一個實驗性標準,演示了通過利用序數理論和銘文,在比特幣的第一層(layer 1)上創建可互換代幣的可能性。Ordinals協議(第一個按照該協議標準所鑄造的代幣)允許內容,包括文本、圖像或視頻,被銘記在比特幣最小單位 — — 聰(Satoshi)上,從而創造出獨特的數字資産。

序數理論是在BTC網絡上實現銘文的關鍵。

每個聰本質上是一樣的,Ordinals通過敘述理論製定了一套聰的排序協議,這個排序基於聰的挖出和他們交易輸入和輸出的順序

序數有幾種不衕的錶示方法:

  • 整數錶示法:2099994106992659 是根據聰挖掘的順序分配的序數。
  • 小數錶示法:3891094.16797 第一個數字是聰被挖掘的區塊高度,第二個數字是聰在區塊內的偏移量。
  • 度數錶示法:3°111094′214″16797‴。稍後我們會講到這個。
  • 百分位錶示法:99.99971949060254%。錶示聰在比特幣供應中的位置,用百分比錶示。

度數錶達法中包含四個部分:A°B′C″D‴,併且A,B,C,D代錶著不衕的含義:

  • A:周期,從0開始編號。 (周期循環:每六次減半就會髮生一些神奇的事情:減半和難度調整會衕時髮生,這就是所謂的相合,相合之間的時間周期是一個周期。大約每24年就會髮生一次相合,第一次相合應該會髮生在2032年的某個時候。)
  • 減半時代內的區塊索引。
  • 難度調整期間的區塊索引。
  • 區塊內聰的索引。

敘述理論通過度數錶達法來確定一個聰的順序,併且通過順序來給每個聰定義不衕的稀有程度,從而實現每個聰的獨一無二

  • 普通:區塊中的任意非第一個聰。
  • 罕見:每個區塊的第一個聰。
  • 稀有:每個難度調整周期的第一個聰。
  • 史詩:每個減半時代的第一個聰。
  • 傳説:每個周期的第一個聰。
  • 神話:創世區塊中的第一個聰。

舉例説明,比如現有一個度數錶達爲 1°1′0″0‴ ,其中

  • 1°:代錶第二個循環周期
  • 1′:代錶不是減半周期的第一個區塊
  • 0″:代錶難度調整的第一個區塊
  • 0‴ :代錶區塊的第一顆聰

通過上麵的稀有度定義,這個聰被定義爲罕見的聰。

大緻的流程如下所緻:

在Ordinals中是如何通過代碼實現的呢?

py# 計算給定高度的塊的敘述(獎勵)

def subsidy(height):

return 50 * 100_000_000 >> height // 210_000

這個函數用於計算給定高度的比特幣塊的獎勵,其中 50 * 100_000_000 是比特幣的起始獎勵,>> 是右移位運算符,相當於除以 2 的整數除法。這個函數返回一個整數,錶示在給定高度的塊的獎勵數量。

計算給定高度的塊的第一個獎勵的序數

def first_ordinal(height):

start = 0

for h in range(height):

start += subsidy(h)

return start

這個函數計算在給定高度的塊的第一個獎勵的序數。通過迭代高度併纍加每個塊的獎勵,計算從第一個塊到給定高度的總獎勵數量,從而得到第一個獎勵的序數。

爲給定塊分配序數

def assign_ordinals(block):

first = first_ordinal(block.height)

last = first + subsidy(block.height)

coinbase_ordinals = list(range(first, last))

爲給定塊分配序數

def assign_ordinals(block):

first = first_ordinal(block.height)

last = first + subsidy(block.height)

coinbase_ordinals = list(range(first, last))

for transaction in block.transactions[1:]:

ordinals = []

for input in transaction.inputs:

 ordinals.extend(input.ordinals)

for output in transaction.outputs:

 output.ordinals = ordinals[:output.value]

 del ordinals[:output.value]

coinbase_ordinals.extend(ordinals)

for output in block.transactions[0].outputs:

output.ordinals = coinbase_ordinals[:output.value]

del coinbase_ordinals[:output.value]

這個函數用於爲給定的比特幣塊分配序數。它首先計算塊的第一個和最後一個獎勵的序數範圍。接下來,它迭代塊中的每個交易,爲每個輸出分配序數。最後,爲交易的輸出分配序數,以確保整個塊中的所有聰都有唯一的序數。

簡而言之,通過序數理論,oridinals將本質上每個相衕的聰(Satoshi) 通過加工變得獨一無二起來,併且通過規則爲每一個聰定義稀有熟悉, 實現收藏屬性或者適製定玩法的規則。

使用場景

  • 趣味性:獨特有趣的協議將會爲比特幣生態再次帶來繁榮。
  • 資産髮行:brc-20代幣可以作爲資産、權益或其他可互換實體的數字錶示。這些可以是穩定幣、實用代幣,也可以是基於meme的代幣。
  • dApp集成:開髮人員可以將brc-20代幣集成到利用比特幣網絡的去中心化應用程序中。它們的應用範圍從産生收益和抵押貸款到權益質押等多方麵。
  • 資産代幣化:brc-20標準促進了任何資産或權益的代幣化,打開了許多可能性,例如基於代幣的社區或DAO投票。
  • 交換機製:brc-20代幣可以通過各種平颱在比特幣網絡的第一層進行便捷的交換和交易。雖然它們目前可以通過訂單簿進行訪問,但將它們整合到流動性池交換中的計畫已經在近期出現在大衆視野中

Arc-20技術實現

Atomicals 協議是一個簡單而靈活的協議,用於在未花費的交易輸出(UTXO)區塊鏈(如比特幣)上鑄造、轉移和更新數字對象(傳統上稱爲非衕質化代幣)。一個 Atomical(或稱爲 “atom”) 是一種管理數字對象的創建、轉移和更新的方式 — — 本質上是根據一些簡單規則定義的數字所有權鏈。

Arc-20採用了染色幣模型,也就是説一個Arc-20 token都必鬚有一個聰支持,而非像Brc-20通過排序進行區分。由於Arc-20 代幣完全基於聰,使得他可以像Btc一樣進行拆分和合併(也就是文章開頭提及的UTXO),併且可以直接通過比特幣網絡進行轉帳。

舉例説明,通過Atomicals 協議,我們將指定的100個聰定義爲100張“電影票”,用戶可以在支持Atomicals協議的電影院,拿這100個聰中的一個來支付,充當電影票的職能

但是礦工和比特幣網絡併不能知道哪個UTXO經過了”Atomicals”化,從而可能誤把Arc-20代幣當成礦工費用,爲了解決這一問題,Artomicals通過指令操作,將每一個Arc-20代幣都作爲交易的第一個輸出來避免代幣的誤銷毀。

使用場景

  • 數字收藏品、媒體和藝術
  • 數字身份、身份驗證和令牌門控內容。
  • Web托管和文件存儲
  • 點對點交換和原子交換
  • 數字命名空間分配
  • 虛擬土地和所有權註冊
  • 游戲中的動態對象和狀態
  • 社交媒體個人資料、帖子和社區
  • 任何安全性和去中心化是關鍵問題的地方。具備軍用級別的安全性和驗證要求。

Brc-20 vs Arc-20

接下來,我們將分析比較兩個協議的異衕。

Brc-20

協議大緻分爲三步

  • 部署者需要將代幣的相關信息按照協議格式寫入至BTC鏈上

{

“p”: “brc-20”,

“op”: “deploy”,

“tick”: “ordi”,

“max”: “21000000”,

“lim”: “1000”

}

  • 索引器讀取鏈上代幣相關數據
  • 鏈下賬本記録代幣的相關餘額,處理轉賬

由於部署者在部署代幣時,代幣信息本身無法被BTC所識別,因此需要一個索引器(indexer)來穫取鏈上相關數據併通過該數據在鏈下創建一個賬本來記録相關歷史以及處理相關操作併進行數據更新。

鏈下索引器需要精準的捕穫每次一代幣操作併更新線下賬本。但衕區塊鏈一樣,隨著交易的增多,節點存儲的數據將會越來越大,如何保證賬本的完整性以及在龐大的數據量中找到需要更改的信息,將會成爲brc-20的挑戰

Arc-20

衕樣的,Arc-20協議在部署代幣時也需要在BTC鏈上根據格式記録相關信息

program.command(‘init-dft’)

.description(‘Initialize fungible token (FT) atomical in decentralized issuance mode’)

.argument(‘<ticker>’, ‘string’)

.argument(‘<mint_amount>’, ‘number’)

.argument(‘<max_mints>’, ‘number’)

.argument(‘<mint_height>’, ‘number’)

.argument(‘<file>’, ‘string’)

.option(‘—rbf’, ‘Whether to enable RBF for transactions.’)

.option(‘—funding <string>’, ‘Use wallet alias wif key to be used for funding and change’)

.option(‘—satsbyte <number>’, ‘Satoshis per byte in fees’, ‘15’)

.option(‘—mintbitworkc <string>’, ‘Whether to require any bitwork proof of work to mint. Applies to the commit transaction.’)

.option(‘—mintbitworkr <string>’, ‘Whether to require any bitwork proof of work to mint. Applies to the reveal transaction.’)

.option(‘—bitworkc <string>’, ‘Whether to put any bitwork proof of work into the token mint. Applies to the commit transaction.’)

.option(‘—bitworkr <string>’, ‘Whether to put any bitwork proof of work into the token mint. Applies to the reveal transaction.’)

.option(‘—parent <string>’, ‘Whether to require a parent atomical to be spent along with the mint.’)

.option(‘—parentowner <string>’, ‘Wallet owner of the parent to spend along with the mint.’)

.option(‘—disablechalk’, ‘Whether to disable the real-time chalked logging of each hash for Bitwork mining. Improvements mining performance to set this flag’)

.action(async (ticker, mintAmount, maxMints, mintHeight, file, options) => {

…..

}

atomicals-js cli源碼中可以找到初始化一個代幣的相關指令,必鬚要在鏈上記録的參數有:

ticker: 代幣名稱

mint_amount: mint總量

max_mints: 單次mint數量

mint_height: 指定開始mint的區塊高度

file: 相關元數據

但與Brc20不衕的是, Arc20採用了染色幣模型,在代幣相關信息録入BTC鏈上後,該協議將會把代幣與Sats做錨定:1 token = 1 sat。

衕時,染色幣模型的使用使得用戶在進行交易時可以直接通過BTC網絡實現而非鏈下賬本,因爲代幣餘額與UTXO中的聰保持一緻,代幣的相關變化都可以在鏈上直觀的反映。索引器在Arc-20中隻是用來讀取代幣在鏈上的相關部署信息,併且驗證哪些是符合Arc-20協議的代幣。

總結

Brc-20的設計結構更依賴與鏈下賬本,而Arc-20更符合Btc的相關特性,併且相較於Brc-20會更去中心化。但衕時,染色幣模型使得Arc-20無法完成meme幣的髮售,因爲meme幣往往有很高的代幣總數,而1 token = 1 sat這一特性使得在髮售meme幣時需要消耗大量Btc

聲明:

  1. 本文轉載自[medium],著作權歸屬原作者[@YanAemons],如對轉載有異議,請聯繫Gate Learn團隊,團隊會根據相關流程盡速處理。
  2. 免責聲明:本文所錶達的觀點和意見僅代錶作者個人觀點,不構成任何投資建議。
  3. 文章其他語言版本由Gate Learn團隊翻譯, 在未提及Gate.io的情況下不得覆製、傳播或抄襲經翻譯文章。
即刻開始交易
註冊並交易即可獲得
$100
和價值
$5500
理財體驗金獎勵!
It seems that you are attempting to access our services from a Restricted Location where Gate.io is unable to provide services. We apologize for any inconvenience this may cause. Currently, the Restricted Locations include but not limited to: the United States of America, Canada, Cambodia, Cuba, Iran, North Korea and so on. For more information regarding the Restricted Locations, please refer to the User Agreement. Should you have any other questions, please contact our Customer Support Team.