mirror of
https://github.com/XRPLF/xrpl-dev-portal.git
synced 2025-11-28 07:35:50 +00:00
cli conflict resolution
This commit is contained in:
ddawson
42
content/concepts/interoperability/intro-to-evm-sidechain.md
Normal file
42
content/concepts/interoperability/intro-to-evm-sidechain.md
Normal file
@@ -0,0 +1,42 @@
|
||||
---
|
||||
html: intro-to-evm-sidechain.html
|
||||
parent: xrpl-interoperability.html
|
||||
blurb: Introduction to the EVM compatible XRP Ledger Sidechain
|
||||
labels:
|
||||
- Interoperability
|
||||
status: not_enabled
|
||||
---
|
||||
# Introduction to EVM Compatible XRP Ledger Sidechain
|
||||
|
||||
The Ethereum Virtual Machine (EVM) compatible XRP Ledger sidechain is a secure and fast public blockchain that brings all kinds of web3 applications to the XRP Ledger community.
|
||||
|
||||
- Explorer: [https://evm-sidechain.xrpl.org](https://evm-sidechain.xrpl.org/)
|
||||
- Public RPC: [https://rpc-evm-sidechain.xrpl.org](https://rpc-evm-sidechain.xrpl.org/)
|
||||
|
||||
|
||||
The EVM Sidechain is a powerful latest generation blockchain with the following features:
|
||||
|
||||
- Supports up to 1000 transactions per second, thus handling large loads and throughput.
|
||||
- Has a low transaction confirmation time, on average, as a block is produced every 5 seconds.
|
||||
- Once a block is added to the chain and confirmed, it is considered final (1 block finalization time).
|
||||
- Provides full Ethereum Virtual Machine (EVM) compatibility, enabling you to connect your wallet and interact or deploy smart contracts written in Solidity.
|
||||
|
||||
## Consensus
|
||||
|
||||
The EVM Sidechain runs on a proof-of-stake (PoS) consensus algorithm. Staking is when you pledge your coins to be used for verifying transactions. The proof-of-stake model allows you to stake cryptocurrency (also referred to as "coins") and create your own validator nodes. Your coins are locked up while you stake them, but you can unstake them if you want to trade your coins.
|
||||
|
||||
In a proof-of-stake blockchain, mining power depends on the amount of coins a validator is staking. Participants who stake more coins are more likely to be chosen to add new blocks.
|
||||
|
||||
If you are interested in staking cryptocurrency and running your own validator, see [Join EVM Sidechain Devnet](join-evm-sidechain-devnet.html) for more information.
|
||||
|
||||
The underlying technology for the XRP Ledger EVM Sidechain consensus is [Tendermint](https://tendermint.com/), a Byzantine-Fault Tolerant engine for building blockchains.
|
||||
|
||||
The blockchain uses the `cosmos-sdk` library on top of Tendermint to create and customize the blockchain using its built-in modules. The EVM sidechain uses the [Ethermint](https://github.com/evmos/ethermint) `cosmos-sdk` module, which provides EVM compatibility
|
||||
|
||||
## Interoperability Using the EVM Sidechain
|
||||
|
||||
The EVM sidechain is directly connected to XRP Ledger through the XRP Ledger bridge ([https://bridge.devnet.xrpl.](https://bridge.devnet.xrpl.org/). Through this bridge component, you can move your XRP to the EVM Sidechain and use its features.
|
||||
|
||||
## See Also
|
||||
|
||||
[Get Started with EVM Sidechain](get-started-evm-sidechain.html)
|
||||
@@ -26,7 +26,7 @@ With a stablecoin on the XRP Ledger and use Authorized Trust Lines, the process
|
||||
3. The customer sends a `TrustSet` transaction to create a trust line to the issuer's address, with a positive limit.
|
||||
4. The issuer sends a `TrustSet` transaction to authorize the customer's trust line.
|
||||
|
||||
**Tip:** The issuer can authorize a trust line preemptively (step 3), before the customer has created it. This creates a trust line with zero limit, so that the customer's TrustSet transaction (step 2) sets the limit on the pre-authorized trust line. _(Added by the TrustSetAuth amendment.)_
|
||||
**Tip:** The two TrustSet transactions (steps 3 and 4) can occur in either order. If the issuer authorizes the trust line first, this creates a trust line with the limit set to 0, and the customer's TrustSet transaction sets the limit on the pre-authorized trust line. _(Added by the [TrustSetAuth amendment][].)_
|
||||
|
||||
## As a Precaution
|
||||
|
||||
|
||||
96
content/concepts/tokens/freezes.ja.md
Normal file
96
content/concepts/tokens/freezes.ja.md
Normal file
@@ -0,0 +1,96 @@
|
||||
---
|
||||
html: freezes.html
|
||||
parent: tokens.html
|
||||
blurb: 凍結では、コンプライアンス目的で発行済み通貨の取引を停止できます。
|
||||
labels:
|
||||
- トークン
|
||||
---
|
||||
# 発行済み通貨の凍結
|
||||
|
||||
XRPは発行済み通貨ではありません。XRPはXRP Ledgerのネイティブ資産であり、XRP Ledgerでのトランザクションの実行に必要となります。XRPは取引相手を必要としません。つまり、XRPを保有しているということは負債ではなく実際の通貨であるXRPを保有していることになります。このため、_**<u>いかなる組織または個人もXRPを凍結できません</u>**_。
|
||||
|
||||
XRP Ledgerでは、XRP以外の通貨はすべて発行済み通貨として表すことができます。このような発行済み通貨（「イシュアンス」または「IOU」とも呼ばれます）は、「トラストライン」と呼ばれるアドレス間の会計上の関係で管理されます。発行済み通貨は通常、負債とも資産とも見なされるため、トラストラインの残高は、見る視点によってマイナスにもプラスにもなります。どのアドレスも（XRP以外の）通貨を自由に発行できますが、他のアドレスが希望する保有量によってのみ制限されます。
|
||||
|
||||
特定のケースでは、法的要件への準拠や、疑わしい活動の調査のために、取引所またはゲートウェイが、XRP以外の発行済み通貨の残高を急きょ凍結することがあります。
|
||||
|
||||
**ヒント:** 誰もXRPを凍結することはできません。
|
||||
|
||||
凍結については、3種類の設定があります。
|
||||
|
||||
* [**Individual Freeze**](#individual-freeze) - 1件の取引相手を凍結します。
|
||||
* [**Global Freeze**](#global-freeze) - 取引相手全員を凍結します。
|
||||
* [**No Freeze**](#no-freeze) - 個々の取引相手の凍結機能と、Global Freezeを終了できる機能を永久に放棄します。
|
||||
|
||||
凍結機能は発行済み通貨にのみ適用されます。XRP Ledgerには特権的な立場の当事者は存在しないため、凍結機能では、取引相手が、XRPまたはその他の取引相手が発行した資金で取引を実行することを阻止できません。Rippleを含め誰もXRPを凍結することはできません。
|
||||
|
||||
凍結対象の残高がプラス、マイナスにかかわらず、すべての凍結設定を行うことができます。通貨イシュアーまたは通貨保持者のいずれかがトラストラインを凍結できますが、通貨保持者がイシュアーを凍結しても、その影響はわずかです。
|
||||
|
||||
|
||||
## Individual Freeze
|
||||
|
||||
**Individual Freeze**機能は、[トラストライン](trust-lines-and-issuing.html)に関する設定です。発行アドレスがIndividual Freeze設定を有効にすると、そのトラストラインの通貨に対して以下のルールが適用されます。
|
||||
|
||||
* 凍結されたトラストラインの両当事者間の直接決済は、凍結後も可能です。
|
||||
* そのトラストラインの取引相手は、イシュアーへ直接支払う場合を除き、凍結されたトラストラインの残高を減らすことはできません。取引相手は、凍結されたイシュアンスを直接イシュアーに送信することだけが可能です。
|
||||
* 取引相手は、凍結されたトラストライン上で引き続きその他の当事者からの支払を受け取ることができます。
|
||||
* 取引相手が凍結されたトラストライン上の発行済み通貨の売りオファーを出した場合、[資金不足とみなされます](offers.html#オファーのライフサイクル)。
|
||||
|
||||
確認事項: トラストラインではXRPは保持されません。XRPは凍結できません。
|
||||
|
||||
金融機関は、疑わしい活動を行う取引相手や、金融機関の利用規約に違反する取引相手にリンクしているトラストラインを凍結できます。金融機関は、同機関が運用する、XRP Ledgerに接続されているその他のシステムにおいても、その取引相手を凍結する必要があります。（凍結しないと、アドレスから金融機関経由で支払を送金することで、望ましくない活動を行うことが依然として可能となります。）
|
||||
|
||||
各個別アドレスは金融機関とのトラストラインを凍結できます。これは金融機関とその他のユーザーの間の取引には影響しません。ただし、他のアドレス（[運用アドレス](issuing-and-operational-addresses.html)を含む）からその個別アドレスに対しては、その金融機関のイシュアンスを送信できなくなります。このようなIndividual Freezeは、オファーには影響しません。
|
||||
|
||||
Individual Freezeは1つの通貨にのみ適用されます。特定の取引相手の複数通貨を凍結するには、アドレスが各通貨のトラストラインで、個別にIndividual Freezeを有効にする必要があります。
|
||||
|
||||
[No Freeze](#no-freeze)設定を有効にしている場合、アドレスはIndividual Freeze設定を有効にできません。
|
||||
|
||||
|
||||
## Global Freeze
|
||||
|
||||
**Global Freeze**機能は、アドレスに設定できます。発行アドレスがGlobal Freeze機能を有効にすると、その発行アドレスのすべての発行済み通貨に対して以下のルールが適用されます:
|
||||
|
||||
* 凍結された発行アドレスのすべての取引相手は、イシュアーに直接支払う場合を除き、凍結されたアドレスへのトラストラインの残高を減らすことができません。（これはすべての[運用アドレス](issuing-and-operational-addresses.html)にも影響します。）
|
||||
* 凍結された発行アドレスの取引相手は、発行アドレスとの直接的な支払の送受信を引き続き行うことができます。
|
||||
* 凍結アドレスによる発行済み通貨の売りオファーはすべて、[資金不足とみなされます](offers.html#オファーのライフサイクル)。
|
||||
|
||||
確認事項: アドレスはXRPを発行できません。Global FreezeはXRPには適用されません。
|
||||
|
||||
運用アドレスのシークレットキーが漏えいした場合には、運用アドレスの制御を取り戻した後であっても金融機関の[発行アドレス](issuing-and-operational-addresses.html)に対してGlobal Freezeを有効にすることが有益です。これにより資金流出を止め、攻撃者がそれ以上の資金を盗むことを防止し、少なくともそれまでの経過の追跡が容易になります。XRP LedgerでGlobal Freezeを行う他に、金融機関は外部システムへのコネクターでの疑わしい活動を停止する必要があります。
|
||||
|
||||
また、金融機関が新しい[発行アドレス](issuing-and-operational-addresses.html)への移行や、営業の停止を予定している場合にも、Global Freezeを有効にすることが有用です。これにより、特定の時点で資金がロックされるため、ユーザーは他の通貨で取引することができなくなります。
|
||||
|
||||
Global Freezeは、当該アドレスによって発行および保有されている _すべての_ 通貨に適用されます。1つの通貨のみに対してGlobal Freezeを有効にすることはできません。一部の通貨のみを凍結できるようにしたい場合は、通貨ごとに異なるアドレスを使用してください。
|
||||
|
||||
アドレスのGlobal Freeze設定はいつでも有効にできます。ただし、アドレスの[No Freeze](#no-freeze)設定を有効にすると、Global Freezeを _無効にする_ ことはできません。
|
||||
|
||||
|
||||
## No Freeze
|
||||
|
||||
**No Freeze**機能をアドレスに設定すると、取引相手が発行した通貨を凍結する機能を永久に放棄します。この機能を使用すれば、企業は自社が発行した資金を「物理的なお金のように」扱うことができます。これにより、企業は顧客どうしがその資金を取引することに介入できなくなります。
|
||||
|
||||
確認事項: XRPはすでに凍結できません。No Freeze機能は、XRP Ledgerで発行された他の通貨にのみ適用されます。
|
||||
|
||||
No Freeze設定には次の2つの効果があります。
|
||||
|
||||
* 発行アドレスは、すべての取引相手とのトラストラインに対してIndividual Freezeを有効にできなくなります。
|
||||
* 発行アドレスは、Global Freezeを有効にしてグローバル凍結を施行できますが、Global Freezeを _無効にする_ ことはできません。
|
||||
|
||||
XRP Ledgerは金融機関に対し、その発行資金が表す債務を履行することを強制できません。このため、Global Freezeを有効にする機能を放棄しても顧客を保護できません。ただし、Global Freezeを _無効にする_ 機能を放棄することで、Global Freeze機能が一部の顧客に対して不当に適用されないようにすることができます。
|
||||
|
||||
No Freeze設定は、アドレスに対して発行される通貨と、アドレスから発行される通貨のすべてに適用されます。一部の通貨のみを凍結できるようにしたい場合は、通貨ごとに異なるアドレスを使用してください。
|
||||
|
||||
No Freeze設定は、アドレスのマスターキーのシークレットキーにより署名されたトランザクションでのみ有効にできます。[レギュラーキー](setregularkey.html)または[マルチ署名済みトランザクション](multi-signing.html)を使用してNo Freezeを有効にすることはできません。
|
||||
|
||||
|
||||
<!--{# TODO: update "See Also" with new tutorials' technical details #}-->
|
||||
|
||||
|
||||
# 関連項目
|
||||
|
||||
* [凍結コードの例](https://github.com/XRPLF/xrpl-dev-portal/tree/master/content/_code-samples/freeze)
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -82,7 +82,6 @@ You can only enable the No Freeze setting with a transaction signed by your addr
|
||||
<!--
|
||||
# See Also
|
||||
|
||||
- [GB-2014-02 New Feature: Balance Freeze](https://ripple.com/files/GB-2014-02.pdf)
|
||||
- [Freeze Code Samples](https://github.com/XRPLF/xrpl-dev-portal/tree/master/content/_code-samples/freeze)
|
||||
- **Concepts:**
|
||||
- [Trust Lines and Issuing](trust-lines-and-issuing.html)
|
||||
|
||||
@@ -4,6 +4,7 @@ parent: non-fungible.html
|
||||
blurb: You can mint non-fungible tokens in batches.
|
||||
labels:
|
||||
- Tokens
|
||||
|
||||
---
|
||||
# Batch minting
|
||||
|
||||
@@ -24,7 +25,7 @@ Any market activity prior to the initial sale of the NFToken object is not recor
|
||||
|
||||
## Scripted Minting
|
||||
|
||||
Use a program or script to mint many tokens at once. You might find the XRP Ledger ticket functionality helps you submit transactions in parallel, up to a current limit of 200 transactions in one group.
|
||||
Use a program or script to mint many tokens at once. You might find that [Tickets](tickets.html) help you submit transactions in parallel, up to a current limit of 200 transactions in one group.
|
||||
|
||||
For a practical example, see the [Batch Mint NFTokens](batch-minting.html) tutorial.
|
||||
|
||||
@@ -35,4 +36,4 @@ For a practical example, see the [Batch Mint NFTokens](batch-minting.html) tutor
|
||||
|
||||
### Downside
|
||||
|
||||
You need to retain the appropriate XRP reserve for all of the NFToken objects you mint. As a rule of thumb, this is roughly 1/12th XRP per NFToken object at the current reserve rate. In the event that you do not have sufficient XRP in reserve, your mint transactions fail until you add sufficient XRP to your account.
|
||||
You need to retain the appropriate XRP reserve for all of the NFToken objects you mint. As a rule of thumb, this is roughly 1/12th XRP per NFToken object at the current reserve rate. In the event that you do not have sufficient XRP in reserve, your mint transactions fail until you add sufficient XRP to your account.
|
||||
|
||||
86
content/concepts/tokens/non-fungible-token-transfers.ja.md
Normal file
86
content/concepts/tokens/non-fungible-token-transfers.ja.md
Normal file
@@ -0,0 +1,86 @@
|
||||
---
|
||||
html: non-fungible-token-transfers.html
|
||||
parent: non-fungible-tokens.html
|
||||
blurb: NFTokenをダイレクトモードまたはブローカーモードで取引する。
|
||||
filters:
|
||||
- include_code
|
||||
labels:
|
||||
- Non-fungible Tokens, NFTs
|
||||
status: not_enabled
|
||||
---
|
||||
|
||||
# XRP Ledger上でNFTokenを売買する
|
||||
|
||||
XRP Ledger上のアカウント間で`NFToken`オブジェクトを転送することができます。`NFToken` の売買をオファーしたり、他のアカウントから自分が保有する NFToken への売買オファーを受け入れることができます。`NFToken` を 無料(価格が0)で売却することで、`NFToken` を配布することもできます。すべてのオファーは [NFTokenCreateOfferトランザクション][] を使って作成されます。
|
||||
|
||||
_([NonFungibleTokensV1_1 amendment][]が必要です)_
|
||||
|
||||
## 売却オファー
|
||||
|
||||
|
||||
### 売却オファーの作成
|
||||
|
||||
`NFToken` オブジェクトの所有者であれば、`tfSellToken` フラグを指定して [NFTokenCreateOffer トランザクション][] を使用して売却オファーを作成することができます。`NFTokenID` と、対価として受け取る金額 `Amount` を指定します。オプションで、そのオファーが無効になる `Expiration` と、その `NFToken` を購入することができる唯一のアカウントである `Destination` を指定することができます。
|
||||
|
||||
|
||||
### 売却オファーを受け入れる
|
||||
|
||||
販売されている `NFToken` を購入するには、`NFTokenAcceptOffer` トランザクションを使用します。`NFTokenOffer` オブジェクトの所有者アカウントと `NFTokenOfferID` を指定し、受け入れることを決定します。
|
||||
|
||||
|
||||
## 購入オファー
|
||||
|
||||
|
||||
### 購入オファーの作成
|
||||
|
||||
どのアカウントでも `NFToken` の購入オファーを作成することができます。`tfSellToken` のフラグを指定せずに、[NFTokenCreateOffer][] を使用することで、購入オファーを作成することが可能です。`Owner`アカウント、`NFTokenID`、オファーの `Amount` を指定します。
|
||||
|
||||
|
||||
### 購入オファーを受け入れる
|
||||
|
||||
`NFTokenAcceptOffer` トランザクションを使用して `NFToken` を転送します。`NFTokenOfferID` と所有者アカウントを指定して、トランザクションを完了させてください。
|
||||
|
||||
|
||||
## 取引モード
|
||||
|
||||
`NFToken`を取引する場合、購入者と販売者の間で直接取引を行う、 _ダイレクト_ 取引と、第三者の口座が売りと買いのオファーをマッチングして取引を仲介する、 _ブローカー_ 取引を選択することができます。
|
||||
|
||||
ダイレクトモードでの取引では、販売者が転送をコントロールすることができます。販売者は誰でも購入できるように `NFToken` を出品するか、特定の取引先アカウントに `NFToken` を販売することができます。販売者はNFTokenの販売価格全額を受け取ります。
|
||||
|
||||
ブローカーモードでは、販売者は第三者のアカウントに`NFToken`の販売を仲介させます。ブローカーアカウントは、合意したレートで仲介手数料を徴収し、転送を行います。購入はリアルタイムで完了し、ブローカーと販売者には購入資金から支払われ、ブローカーによる前払いは必要ありません。
|
||||
|
||||
|
||||
### ブローカーモードを使用する場合
|
||||
|
||||
`NFToken`の作成者が適切な購入者を探す時間と忍耐力がある場合、作成者は販売から得たすべての収益を得ることができます。これは、少数の`NFToken`オブジェクトを様々な価格で販売するクリエイターにとって、非常に有効な方法です。
|
||||
|
||||
一方、クリエイターは、創作に時間を割くことができるのに、販売に時間を割くのは抵抗があるのではないでしょうか。そのような場合、個別に対応するのではなく、第三者であるブローカーのアカウントに販売業務を委託することが可能です。
|
||||
|
||||
ブローカーを利用すると、いくつかの利点があります。例えば
|
||||
|
||||
* ブローカーは仲介者として、`NFToken`の販売価格を最大化するために活動することができます。ブローカーが販売価格の何割かを受け取る場合、価格が高ければ高いほど、ブローカーの収入も増えます。
|
||||
* ブローカーは、ニッチな市場や 価格帯などの基準に基づいて`NFToken`オブジェクトの管理を行う管理者として活動することができます。これによって、クリエイターの作品を発見できないような購入者のグループを呼び込むことができるでしょう。
|
||||
* ブローカーは、Opensea.ioのようなマーケットプレイスとして機能し、アプリケーション層でオークション機能を提供することもできます。
|
||||
|
||||
|
||||
### ブローカー販売のワークフロー
|
||||
|
||||
最も単純なワークフローでは、クリエイターが新しい`NFToken`を発行します。クリエイターは売却オファーを作成する際、最低売却価格を入力し、売却先にブローカーを設定します。購入希望者はブローカーを経由して`NFToken`に入札を行います。ブローカーは落札者を選び、取引を完了させ、ブローカー手数料を受け取ります。ベストプラクティスとして、ブローカーは`NFToken`に対して残っている購入オファーをすべてキャンセルします。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
もう1つのワークフローは、クリエイターが販売をよりコントロールできるようにするものです。このワークフローでは、クリエイターが新しい`NFToken`を発行します。入札者はオファーを作成し、ブローカーを宛先として設定します。ブローカーは落札者を選び、仲介手数料を差し引き、`NFTokenCreateOffer`を使用してクリエイターに署名の依頼をします。クリエーターは要求されたオファーに署名し、ブローカーを宛先として設定します。ブローカーは `NFTokenAcceptOffer` を使って売却を完了し、仲介手数料を保持します。ブローカーは `NFTokenCancelOffer` を使用して `NFToken` に対する残りの入札をキャンセルします。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
所有者が他のアカウントで作成した `NFToken` をリセールする場合にも、同じワークフローを使用することができます。
|
||||
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -9,6 +9,8 @@ labels:
|
||||
|
||||
You can transfer `NFToken` objects between accounts on the XRP Ledger. You can offer to buy or sell a `NFToken`, or accept offers from other accounts to buy a `NFToken` you own. You can even give away a `NFToken` by offering to sell it at a price of 0. All offers are created using `NFTokenCreateOffer` transaction.
|
||||
|
||||
_(Added by the [NonFungibleTokensV1_1 amendment][].)_
|
||||
|
||||
|
||||
## Sell Offers
|
||||
|
||||
|
||||
84
content/concepts/tokens/non-fungible-tokens.ja.md
Normal file
84
content/concepts/tokens/non-fungible-tokens.ja.md
Normal file
@@ -0,0 +1,84 @@
|
||||
---
|
||||
html: non-fungible-tokens.html
|
||||
parent: tokens.html
|
||||
blurb: XRPL NFTの紹介。
|
||||
filters:
|
||||
- include_code
|
||||
labels:
|
||||
- Non-fungible Tokens, NFTs
|
||||
---
|
||||
|
||||
# NFTのコンセプトの概要
|
||||
|
||||
XRP Ledgerは、_IOUs_ としても知られる[発行済み通貨](tokens.html)のサポートを提供しています。このような資産は、主に、代替可能(Fungible)です。
|
||||
|
||||
> 代替可能性
|
||||
>
|
||||
> 1. 個々の単位が本質的に交換可能であり、各部分が別の部分と区別できない商品または商品の特性である
|
||||
|
||||
代替可能トークンは、XRP Ledgerの分散型取引所において、ユーザー間でXRPや他の発行済み通貨と手軽に交換することができます。そのため、決済に適しています。
|
||||
|
||||
|
||||
例えば、切手などがそうです。1919年当時、あなたが航空便で手紙を送る必要がある場合、24セントの切手を購入し、封筒に張ったでしょう。もしその切手をなくしてしまったら、別の24セント切手を使うか、10セント切手2枚と2セント切手2枚を使うことができます。非常に使い勝手がいいのです。
|
||||
|
||||
|
||||
|
||||
しかし、1919年という時代のことですから、切手の飛行機が偶然にも逆さまに印刷されている24セントの航空郵便切手が出回るかもしれません。これが世界的に有名な「インバート・ジェニー」切手です。1枚の切手シートで100枚しか流通しなかったため、非常に希少で人気の高い切手です。現在、鑑定では一枚150万円以上の価値があるとされています。
|
||||
|
||||
|
||||
|
||||
これらの切手は、他の24セント切手と交換することはできません。非代替(Non-fungible)になってしまったのです。
|
||||
|
||||
[NonFungibleTokensV1の修正][] :現在有効ではありません: は、XRP Ledgerに非代替性トークン（NFT）のサポートをネイティブで追加するものです。 非代替性トークンは、芸術品やゲーム内アイテムなど、ユニークな物理的、非物理的、あるいは純粋なデジタル商品の所有権をコード化する役割を果たします。
|
||||
|
||||
|
||||
## XRP Ledger上のNFT
|
||||
|
||||
XRP Ledger上では、non-fungible tokenは[NFToken][]オブジェクトとして表されます。NFTokenはユニークで分割できない単位で、決済には使用できません。ユーザーはこのようなトークンを発行（作成）、保有、購入、売却、焼却（破棄）することができます。
|
||||
|
||||
XRP Ledgerでは、容量を節約するために、一つのアカウントで最大32個の `NFToken` オブジェクトを一つの[NFTokenPageオブジェクト][]に格納します。その結果、所有者の `NFToken` オブジェクトに対する [準備金] (reserves.html) は、追加のトークンを格納するためにレジャーが新しいページを作成する場合にのみ増加します。
|
||||
|
||||
また、アカウントは、自分に代わってNFTokenオブジェクトを発行・販売するブローカー（代理発行者）を指定することができます。
|
||||
|
||||
`NFToken` オブジェクトは、トークンが発行された時点で確定し、後で変更することが出来ない設定項目を持ちます。これらは以下の通りです。
|
||||
|
||||
- トークンを一意に定義する各種識別データ。
|
||||
- 発行者が、現在の保有者に関係なく、トークンを焼却できるかどうか。
|
||||
- トークンの保持者がトークンを他者に転送できるかどうか。( `NFToken` は常に発行者に直接送信したり、発行者から送信することが可能です)。
|
||||
- 転送が許可されている場合、発行者は販売価格に対する一定の割合で手数料を徴収することができます。
|
||||
- NFTokenを[発行済み通貨](tokens.html)で売却できるか、XRPのみでしか売却できないか。
|
||||
|
||||
|
||||
## `NFToken`のライフサイクル
|
||||
|
||||
誰もが [NFTokenMint トランザクション][] を使って新しい `NFToken` を作成することができます。`NFToken` は発行者アカウントの [NFTokenPage オブジェクト][] に格納されます。所有者または利害関係者は [NFTokenCreateOffer トランザクション][]を送信して `NFToken` の売買を提案できます。レジャーは提案された転送を [NFTokenOffer オブジェクト][]として追跡し、一方が承諾またはキャンセルすると `NFTokenOffer` を削除します。`NFToken` が転送可能であれば、アカウント間で複数回取引することができます。
|
||||
|
||||
[NFTokenBurn トランザクション][] を使用して、自分が所有する `NFToken` を破棄することができます。発行者が `tfBurnable` フラグを有効にしてトークンを発行した場合、発行者は現在の所有者に関係なくトークンを破棄することが可能です。( 例えば、あるイベントのチケットを表すトークンである場合、そのチケットをある時点で消費するといった場合に便利です)。
|
||||
|
||||
|
||||
|
||||
`NFToken` オブジェクトの転送に関する詳細は、[XRP Ledger上でNFTokenを売買する](non-fungible-token-transfers.html) を参照してください。
|
||||
|
||||
|
||||
## 関連項目
|
||||
|
||||
- [NFToken][] データ型
|
||||
- レジャーオブジェクト
|
||||
- [NFTokenOffer オブジェクト][]
|
||||
- [NFTokenPage オブジェクト][]
|
||||
- トランザクション
|
||||
- [NFTokenMint トランザクション][]
|
||||
- [NFTokenCreateOffer トランザクション][]
|
||||
- [NFTokenCancelOffer トランザクション][]
|
||||
- [NFTokenAcceptOffer トランザクション][]
|
||||
- [NFTokenBurn トランザクション][]
|
||||
- API メソッド
|
||||
- [account_nfts メソッド][]
|
||||
- [nft_sell_offers メソッド][]
|
||||
- [nft_buy_offers メソッド][]
|
||||
- [nft_info メソッド][] (Clioサーバのみ)
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
91
content/concepts/tokens/non-fungible-tokens.md
Normal file
91
content/concepts/tokens/non-fungible-tokens.md
Normal file
@@ -0,0 +1,91 @@
|
||||
---
|
||||
html: non-fungible-tokens.html
|
||||
parent: tokens.html
|
||||
blurb: Introduction to XRPL NFTs.
|
||||
filters:
|
||||
- include_code
|
||||
labels:
|
||||
- Non-fungible Tokens, NFTs
|
||||
---
|
||||
|
||||
# Non-Fungible Tokens Overview
|
||||
|
||||
The XRP Ledger supports non-fungible tokens (NFTs, or “nifties” in the vernacular) natively. Non-fungible tokens serve to encode ownership of unique physical, non-physical, or purely digital goods, such as works of art or in-game items.
|
||||
|
||||
_(Added by the [NonFungibleTokensV1_1 amendment][].)_
|
||||
|
||||
|
||||
## Background
|
||||
|
||||
The XRP Ledger offers support for [tokens](tokens.html), also known as _IOUs_. Such assets are, primarily, fungible.
|
||||
|
||||
> Fun·gi·ble /ˈfənjəbəl/ (adj)
|
||||
>
|
||||
> 1. able to replace or be replaced by another identical item; mutually interchangeable.
|
||||
|
||||
Fungible tokens can be easily traded between users for XRP or other issued assets on the XRP Ledger's decentralized exchange. This makes them ideal for payments.
|
||||
|
||||
|
||||
A good example of a fungible item might be a postage stamp. If you are standing around in 1919 and need to send a letter by airmail, you would purchase a 24-cent stamp and affix it to your envelope. If you lost that stamp, you could use a different 24-cent stamp or use 2 10-cent stamps and 2 2-cent stamps. Very fungible.
|
||||
|
||||
|
||||
|
||||
But since you are standing around in 1919, you might be offered 24-cent airmail stamps where the aeroplane on the stamp is accidentally printed upside down. These are the world famous “Inverted Jenny” stamps. Only 100 were circulated on a single sheet of stamps, making them extremely rare and sought after. The current value of each mint condition stamp is appraised at over $1.5 million dollars.
|
||||
|
||||
|
||||
|
||||
Those stamps cannot be replaced by just another other 24-cent stamp. They have become _non-fungible_.
|
||||
|
||||
To represent digital assets similar to these, use the XRP Ledger's Non-Fungible Tokens feature (sometimes referred to by its standards draft number, [XLS-20](https://github.com/XRPLF/XRPL-Standards/discussions/46)).
|
||||
|
||||
|
||||
## NFTs on the XRP Ledger
|
||||
|
||||
On the XRP Ledger, a non-fungible token is represented as a [NFToken][] object. A `NFToken` is a unique, indivisible unit that is not used for payments. Users can mint (create), hold, buy, sell, and burn (destroy) such tokens.
|
||||
|
||||
The ledger stores up to 32 `NFToken` objects owned by the same account in a single [NFTokenPage object][] to save space. As a result, the owner's [reserve requirement](reserves.html) for `NFToken` objects only increases when the ledger needs to make a new page to store additional tokens.
|
||||
|
||||
Accounts can also designate a broker, or "Authorized Minter", who can mint and sell `NFToken` objects on their behalf.
|
||||
|
||||
`NFToken` objects have several settings that are defined when the token is minted and cannot be changed later. These include:
|
||||
|
||||
- Various identifying data that uniquely defines the token.
|
||||
- Whether the issuer can burn the token regardless of who currently holds it.
|
||||
- Whether the holder of the token can transfer it to others. (The `NFToken` can always be sent to or from the issuer directly.)
|
||||
- If transfers are allowed, the issuer can charge a transfer fee as a percentage of the sale price.
|
||||
- Whether the holder can sell the `NFToken` for [fungible token](tokens.html) amounts, or only for XRP.
|
||||
|
||||
|
||||
## `NFToken` Lifecycle
|
||||
|
||||
Anyone can create a new `NFToken` using the [NFTokenMint transaction][] type. The `NFToken` lives on the [NFTokenPage object][] of the issuing account. Either the owner or an interested party can send a [NFTokenCreateOffer transaction][] to propose buying or selling the `NFToken`; the ledger tracks the proposed transfer as a [NFTokenOffer object][], and deletes the `NFTokenOffer` when either side accepts or cancels the offer. If the `NFToken` is transferable, it can be traded multiple times between accounts.
|
||||
|
||||
You can destroy a `NFToken` you own using the [NFTokenBurn transaction][]. If the issuer minted the token with `tfBurnable` flag enabled, the issuer can also burn the token regardless of the current owner. (This could be useful, for example, for a token that represents a ticket to an event which is used up at some point.)
|
||||
|
||||
|
||||
|
||||
For more info about transferring `NFToken` objects, see [Trading NFTokens on the XRP Ledger](non-fungible-token-transfers.html).
|
||||
|
||||
|
||||
## Reference
|
||||
|
||||
- [NFToken][] data type
|
||||
- Ledger Objects
|
||||
- [NFTokenOffer object][]
|
||||
- [NFTokenPage object][]
|
||||
- Transactions
|
||||
- [NFTokenMint transaction][]
|
||||
- [NFTokenCreateOffer transaction][]
|
||||
- [NFTokenCancelOffer transaction][]
|
||||
- [NFTokenAcceptOffer transaction][]
|
||||
- [NFTokenBurn transaction][]
|
||||
- API Methods
|
||||
- [account_nfts method][]
|
||||
- [nft_sell_offers method][]
|
||||
- [nft_buy_offers method][]
|
||||
- [nft_info method][] (Clio server only)
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -13,13 +13,14 @@ All assets other than XRP can be represented in the XRP Ledger as **tokens**. St
|
||||
|
||||
Any account can issue tokens to other recipients who are willing to hold them, but you cannot unilaterally give tokens away to users who do not want them.
|
||||
|
||||
Standard tokens are fungible, meaning all units of that token are interchangeable and indistinguishable. Non-fungible tokens are also possible: see [Non-Fungible Tokens](non-fungible.md) for details of the XRP Ledger's native support.
|
||||
Standard tokens are fungible: meaning, all units of that token are interchangeable and indistinguishable. Non-fungible tokens are also possible: see [Non-Fungible Tokens](non-fungible-tokens.html) for details of the XRP Ledger's native support.
|
||||
|
||||
Tokens can used for [cross-currency payments](../transactions/payments/cross-currency-payments.md) and can be traded in the <!-- * -->decentralized exchange.
|
||||
|
||||
Tokens can used for [cross-currency payments](cross-currency-payments.html) and can be traded in the <!-- * -->decentralized exchange.
|
||||
|
||||
<!-- * [decentralized exchange](../server/decentralized-exchange.md) -->
|
||||
|
||||
The balance on a trust line is negative or positive depending on which side you view it from. The side with the negative balance is called the "issuer" and can control some properties of how those tokens behave. When you send tokens to another account that isn't the issuer, those tokens "ripple" through the issuer and possibly other accounts using the same currency code. This is useful in some cases, but can cause unexpected and undesirable behavior in others. You can use the [No Ripple flag](rippling.md#the-no-ripple-flag) on trust lines to prevent those trust lines from rippling.
|
||||
The balance on a trust line is negative or positive depending on which side you view it from. The side with the negative balance is called the "issuer" and can control some properties of how those tokens behave. When you send tokens to another account that isn't the issuer, those tokens "ripple" through the issuer and possibly other accounts using the same currency code. This is useful in some cases, but can cause unexpected and undesirable behavior in others. You can use the [No Ripple flag](rippling.html#the-no-ripple-flag) on trust lines to prevent those trust lines from rippling.
|
||||
|
||||
## Token Properties
|
||||
|
||||
@@ -30,9 +31,9 @@ Tokens in the XRP Ledger are <!--*-->fundamentally different than XRP. Tokens al
|
||||
|
||||
Tokens use decimal (base-10) math with 15 digits of precision and an exponent that allows them to express very large values (up to 9999999999999999 × 10<sup>80</sup>) and very small values (down to 1.0 × 10<sup>-81</sup>).
|
||||
|
||||
Anyone can issue tokens by sending a `Payment` transaction if the necessary trust lines are in place. You can "burn" tokens by sending them back to the issuer. In some cases, [cross-currency payments](../transactions/payments/cross-currency-payments.md) or trades can also create more tokens according to an issuer's settings.
|
||||
Anyone can issue tokens by sending a `Payment` transaction if the necessary trust lines are in place. You can "burn" tokens by sending them back to the issuer. In some cases, [cross-currency payments](cross-currency-payments.html) or trades can also create more tokens according to an issuer's settings.
|
||||
|
||||
Issuers can charge a [transfer fee](transfer-fees.md) that is automatically deducted when users transfer their tokens. Issuers can also define a <!-- * -->tick size for exchanges rates involving their tokens. Both issuers and regular accounts can [freeze](freezing-tokens.md) trust lines, which limits how the tokens in those trust lines can be used. (None of these things applies to XRP.)
|
||||
Issuers can charge a [transfer fee](transfer-fees.html) that is automatically deducted when users transfer their tokens. Issuers can also define a <!-- * -->tick size for exchanges rates involving their tokens. Both issuers and regular accounts can [freeze](freezing-tokens.html) trust lines, which limits how the tokens in those trust lines can be used. (None of these things applies to XRP.)
|
||||
|
||||
<!-- * [tick size](ticksize.md) -->
|
||||
|
||||
|
||||
@@ -4,7 +4,7 @@
|
||||
|
||||
For standard tokens, the tokens paid in the transfer fee are burned, and no longer tracked in the XRP Ledger. If the token is backed by off-ledger assets, this reduces the amount of those assets the issuer has to hold in reserve to meet its obligations in the XRP Ledger. Transfer fees are usually not appropriate for tokens that aren't backed with outside assets.
|
||||
|
||||
Non-fungible tokens :not_enabled: can also have transfer fees, but they work differently. For details, see [Non-Fungible Tokens](non-fungible-tokens.html).
|
||||
Non-fungible tokens can also have transfer fees, but they work differently. For details, see [Non-Fungible Tokens](non-fungible-tokens.html).
|
||||
|
||||
The transfer fee does not apply when sending or receiving _directly_ to and from the issuing account, but it does apply when transferring from an [operational address][] to another user.
|
||||
|
||||
|
||||
@@ -20,9 +20,9 @@ Benefits of multi-signing include:
|
||||
|
||||
Before you can multi-sign, you must create a list of which addresses can sign for you.
|
||||
|
||||
The `SignerListSet` transaction defines which addresses can authorize transactions from your address. You can include 1 to 8 addresses in a SignerList. The SignerList cannot include the sender's address and there can be no duplicate entries. You can control how many signatures are needed, in which combinations, by using the *SignerWeight* and *SignerQuorum* values of the SignerList.
|
||||
The [SignerListSet transaction][] defines which addresses can authorize transactions from your address. You can include 1 to 32 addresses in a SignerList. The SignerList cannot include the sender's address and there can be no duplicate entries. You can control how many signatures are needed, in which combinations, by using the *SignerWeight* and *SignerQuorum* values of the SignerList.
|
||||
|
||||
If the `ExpandedSignerList` amendment :not_enabled: is enabled, you can include 1 to 32 addresses in a SignerList.
|
||||
_(Updated by the [ExpandedSignerList amendment][].)_
|
||||
|
||||
### Signer Weight
|
||||
|
||||
@@ -34,7 +34,9 @@ The quorum value is the minimum weight total required to authorize a transaction
|
||||
|
||||
### Wallet Locator
|
||||
|
||||
If the `ExpandedSignerList` amendment :not_enabled: is enabled, you can also add up to 256 bits of arbitrary data to each signer's entry in the list. This data is not required or used by the network, but can be used by smart contracts or other applications to identify or confirm other data about the signers.
|
||||
You can also add up to 256 bits of arbitrary data to each signer's entry in the list. This data is not required or used by the network, but can be used by smart contracts or other applications to identify or confirm other data about the signers.
|
||||
|
||||
_(Added by the [ExpandedSignerList amendment][].)_
|
||||
|
||||
### Examples Using Signer Weight and Signer Quorum
|
||||
|
||||
|
||||
@@ -37,12 +37,6 @@ If more than 20% of validators suddenly go offline all at once, the remaining se
|
||||
Negative UNL has no effect on [stand-alone mode](rippled-server-modes.html) since the server does not use consensus in stand-alone mode.
|
||||
|
||||
|
||||
## Enabling the Negative UNL for Testing
|
||||
|
||||
Negative UNL functionality is currently available for testing on [Devnet](parallel-networks.html). You can test the Negative UNL feature by adding or modifying a `[features]` stanza in your `rippled.cfg` file, as described in [Connect Your rippled to a Parallel Network](connect-your-rippled-to-the-xrp-test-net.html).
|
||||
|
||||
|
||||
|
||||
## How It Works
|
||||
|
||||
The Negative UNL is closely tied to the [consensus process](consensus.html) and is designed with safeguards to maintain the continuity and reliability of the network in adverse situations. When all trusted validators are operating normally, the Negative UNL is unused and has no effect. When some validators appear to be offline or out of sync, the Negative UNL rules take effect.
|
||||
|
||||
Reference in New Issue
Block a user