本日はGeez、Kodas、Chimpers、そしてHV-MTLをAmazonに歓迎します。 これらのコードをオンチェーンで引き換え可能なものにするのは楽しいチャレンジでした。 すべてはBoximusのために作られたシンプルながら強力なRedemptionCodeRegistryによって動かされています。 その仕組みはこうです 1/ 🧵

2/ まず、すべてのコードはオフチェーンで安全に生成されます。各コードには、機能セレクター(4バイト)、トークンID(最大8バイト)、ミントアドレス(20バイト)からなる償還データが割り当てられます。 これはオンチェーンストレージコストを最小限に抑えるために、1バイトに詰め込むよう設計されています。

3/ 各贖回コードはオフチェーンでハッシュ化され、そのハッシュは対応する贖回データを示すマッピングとしてオンチェーンに保存されます。 ハッシュ値のみを保存することで、基礎となるコードが露出するのを防げます。

4/ これらすべてのオンチェーンを保存することで、マークル署名の証明のようなオフチェーンの償還時検証要件を不要にし、データパッキングのおかげで1コードあたりわずか~0.04セントのコストで済みます。

5/ ユーザーは現在、これらのコードをAmazonで購入できます。Othersideでコードを使うと、契約はハッシュを計算し、それを使って贖金データを取得し、使用されていないことを確認(使用マークを付けて)最後にデータを解読してMint契約を呼び出します。

6/ ボキシマスの場合、各コードは贖金時に発行される特定のトークンIDにマッピングされていました。『Feels』では少し工夫が必要でした。 単一のERC721トークンを発行する代わりに、1155トークンのパックを発行します。同じエンコーディング形式を使うために、システムを適応させる必要がありました。

7/ 「トークンID」の代わりに、StickerPackというアイデアを作りました。これは1155内の柔軟でストレージ最適化された構造体で、任意の「ID」に対してどのステッカーをミントするかを保存します。 本日のローンチでは、各コードがパック#1に換算されます。パック#1には1から10までのIDが1つずつ含まれています。

8/面白いのは、これらのステッカーパックにはランダム性の概念が用意されていることです。将来のパックはランダムにマークでき、各トークンIDはX%の確率で引き当てられ、各パックはY回の引き分けがあります。

9/ ここではVRFは不要で、ランダム性はリデンプションコード自体によって決まります。ランダムパックは、引き換えコードと各カードの所有者設定の重みを組み合わせて、どのカードがパックに引かれるかを決定する選択メカニズムを経ます。

10/ ElsesideでFeelsがどのように進化していくのか楽しみです。 次に参加する他のコミュニティはどこでしょうか? 誰が聖杯を作るのか(引き当たり確率は0.01%まで低くなることもある)、そして最初に引き出すのは誰か? メタバースでは、誰もがデジタルのフレックスを必要としています。 楽しもう。