mirror of
https://github.com/XRPLF/xrpl-dev-portal.git
synced 2025-11-20 11:45:50 +00:00
Merge branch 'master' into rippled_180
This commit is contained in:
mDuo13
@@ -348,7 +348,7 @@ WS_HANDLERS["transaction"] = log_tx
|
||||
|
||||
**警告:** 代わりに`transaction.Amount`フィールドを使用すると、[Partial Paymentの悪用](partial-payments.html#partial-paymentの悪用)に対して脆弱になる可能性があります。不正使用者はこの悪用を行ってあなたをだまし、あなたが支払ったよりも多くの金額を交換または引き出すことができます。
|
||||
|
||||
- **[CheckCashトランザクション][]** :not_enabled: では、アカウントは別のアカウントの[CheckCreateトランザクション][]によって承認された金額を受け取ることができます。**CheckCashトランザクション**のメタデータを確認すると、アカウントが受け取った通貨の額を確認できます。
|
||||
- **[CheckCashトランザクション][]**では、アカウントは別のアカウントの[CheckCreateトランザクション][]によって承認された金額を受け取ることができます。**CheckCashトランザクション**のメタデータを確認すると、アカウントが受け取った通貨の額を確認できます。
|
||||
|
||||
- **[EscrowFinishトランザクション][]** は、以前の[EscrowCreateトランザクション][]によって作成された[Escrow](escrow.html)を終了することでXRPを送金できます。**EscrowFinishトランザクション**のメタデータを確認すると、escrowからXRPを受け取ったアカウントと、その額を確認できます。
|
||||
|
||||
|
||||
@@ -94,7 +94,7 @@ Loading: "/etc/opt/ripple/rippled.cfg"
|
||||
|
||||
結果の`account_data`の`Sequence`フィールドにある、アカウントのシーケンス番号をメモします。この後のステップでアカウントのトランザクションに署名するために、このシーケンス番号を把握しておく必要があります。
|
||||
|
||||
[DeletableAccounts Amendment](known-amendments.html#deletableaccounts) :not_enabled:がenabledになっている場合、新しく資金を供給したアカウントの`Sequence`番号は、資金を供給したときの[レジャーインデックス][]と一致します。enabledになっていない場合、新しく資金を供給したアカウントの`Sequence`番号は常に1です。
|
||||
[DeletableAccounts Amendment](known-amendments.html#deletableaccounts)がenabledになっている場合、新しく資金を供給したアカウントの`Sequence`番号は、資金を供給したときの[レジャーインデックス][]と一致します。enabledになっていない場合、新しく資金を供給したアカウントの`Sequence`番号は常に1です。
|
||||
|
||||
<!-- MULTICODE_BLOCK_START -->
|
||||
|
||||
|
||||
@@ -3,7 +3,6 @@ html: use-tickets.html
|
||||
parent: manage-account-settings.html
|
||||
blurb: Use Tickets to send a transaction outside of normal Sequence order.
|
||||
embed_xrpl_js: true
|
||||
status: not_enabled
|
||||
filters:
|
||||
- interactive_steps
|
||||
- include_code
|
||||
@@ -12,22 +11,18 @@ labels:
|
||||
---
|
||||
# Use Tickets
|
||||
|
||||
_(Requires the [TicketBatch amendment][] :not_enabled:)_
|
||||
|
||||
[Tickets](tickets.html) provide a way to send transactions out of the normal order. This tutorial walks through the steps of creating a Ticket, then using it to send another transaction.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
<!-- Source for this specific tutorial's interactive bits: -->
|
||||
<script type="application/javascript" src="assets/js/tutorials/use-tickets.js"></script>
|
||||
{% set use_network = "Devnet" %}<!--TODO: change to Testnet eventually -->
|
||||
{% set use_network = "Devnet" %}<!--TODO: change to Testnet eventually. NOTE, Testnet is a few days behind Mainnet in getting the amendment one enabled -->
|
||||
|
||||
This page provides JavaScript examples that use the [xrpl.js](https://js.xrpl.org/) library. See [Get Started Using JavaScript](get-started-using-javascript.html) for setup instructions.
|
||||
|
||||
Since JavaScript works in the web browser, you can read along and use the interactive steps without any setup.
|
||||
|
||||
Tickets must be enabled. At this time, the [TicketBatch amendment][] :not_enabled: is only available on Devnet.
|
||||
|
||||
|
||||
|
||||
## Steps
|
||||
|
||||
@@ -50,8 +50,8 @@ To configure your server to acquire and store full history, complete the followi
|
||||
0. Set the `[ips_fixed]` stanza of your server's config file to explicitly peer with at least one server that has full history available.
|
||||
|
||||
[ips_fixed]
|
||||
169.55.164.20
|
||||
50.22.123.215
|
||||
169.55.164.20 51235
|
||||
50.22.123.215 51235
|
||||
|
||||
Your server can only download historical data from the peer-to-peer network if one its direct peers has the data available. The easiest way to ensure you can download full history is to peer with a server that already has full history.
|
||||
|
||||
|
||||
@@ -17,19 +17,19 @@ labels:
|
||||
|
||||
0. Xcodeコマンドラインツールをインストールします。
|
||||
|
||||
$ xcode-select --install
|
||||
xcode-select --install
|
||||
|
||||
0. [Homebrew](https://brew.sh/)をインストールします。
|
||||
|
||||
$ ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
|
||||
ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
|
||||
|
||||
0. Homebrewをアップデートします。
|
||||
|
||||
$ brew update
|
||||
brew update
|
||||
|
||||
0. Homebrewを使用して依存関係をインストールします。
|
||||
|
||||
$ brew install git cmake pkg-config protobuf openssl ninja
|
||||
brew install git cmake pkg-config protobuf openssl ninja
|
||||
|
||||
0. Boost 1.75.0以降をインストールします。`rippled`1.7.2はBoost 1.75.0以降と互換性があります。HomebrewのリポジトリにあるBoostの最新バージョンでは不十分であるため、Boostを手動でインストールする必要があります。
|
||||
|
||||
@@ -49,54 +49,54 @@ labels:
|
||||
|
||||
2. 以下のコードをBoostディレクトリーの場所に編集して実行し、Boost環境変数が`.bash_profile`ファイルに追加されるようにします。そうすることで、ログイン時にこの環境変数が自動的に設定されます。
|
||||
|
||||
$ echo $"export BOOST_ROOT=/Users/my_user/boost_1_75_0" >> ~/.bash_profile
|
||||
echo $"export BOOST_ROOT=/Users/my_user/boost_1_75_0" >> ~/.bash_profile
|
||||
|
||||
0. 前のステップで`.bash_profile`ファイルをアップデートした場合には、新しいターミナルウィンドウでそれを読み込みます。例:
|
||||
|
||||
$ source .bash_profile
|
||||
source .bash_profile
|
||||
|
||||
0. 希望の場所に`rippled`ソースコードをクローンし、`rippled`ディレクトリーにアクセスします。これを行うには、Git（Homebrewを使用して前にインストール済み）とGitHubを設定する必要があります。例えば、GitHubアカウントを作成し、SSHキーを設定します。詳細は、[Set up git](https://docs.github.com/en/get-started/quickstart/set-up-git/)を参照してください。
|
||||
|
||||
$ git clone git@github.com:ripple/rippled.git
|
||||
$ cd rippled
|
||||
git clone git@github.com:ripple/rippled.git
|
||||
cd rippled
|
||||
|
||||
0. デフォルトでは、クローンを実行すると`develop`ブランチに移動します。開発作業をしていて、未テストの機能の最新セットを使用したい場合にはこのブランチを使用します。
|
||||
|
||||
最新の安定したリリースを使用したい場合には、`master`ブランチをチェックアウトします。
|
||||
|
||||
$ git checkout master
|
||||
git checkout master
|
||||
|
||||
最新のリリース候補をテストしたい場合には、`release`ブランチをチェックアウトします。
|
||||
|
||||
$ git checkout release
|
||||
git checkout release
|
||||
|
||||
または、[GitHub](https://github.com/ripple/rippled/releases)にリストされたタグ付きのリリースをチェックアウトすることもできます。
|
||||
|
||||
0. クローンしたばかりの`rippled`ディレクトリー内にビルドディレクトリーを作成し、そこにアクセスします。例:
|
||||
|
||||
$ mkdir my_build
|
||||
$ cd my_build
|
||||
mkdir my_build
|
||||
cd my_build
|
||||
|
||||
0. `rippled`を構築します。ハードウェアの仕様にもよりますが、これには約5分ほどかかります。
|
||||
|
||||
$ cmake -G "Unix Makefiles" -DCMAKE_BUILD_TYPE=Debug ..
|
||||
cmake -G "Unix Makefiles" -DCMAKE_BUILD_TYPE=Debug ..
|
||||
|
||||
`CMAKE_BUILD_TYPE`を`Debug`または`Release`ビルドタイプに設定できます。標準的な4つの[`CMAKE_BUILD_TYPE`](https://cmake.org/cmake/help/v3.0/variable/CMAKE_BUILD_TYPE.html)の値がすべてサポートされています。
|
||||
|
||||
0. CMakeを使用してビルドを実行します。ハードウェアの仕様にもよりますが、これには約10分ほどかかります。
|
||||
|
||||
$ cmake --build .-- -j 4
|
||||
cmake --build .-- -j 4
|
||||
|
||||
**ヒント:** この例では、`-j`パラメーターが`4`に設定されています。これにより、4つのプロセスを使用し、並行してビルドします。使用する最適なプロセス数は、お使いのハードウェアで使用可能なCPUコア数によって異なります。`sysctl -n hw.ncpu`を使用して、CPUのコア数を調べてください。
|
||||
|
||||
0. サーバー実行可能ファイルに組み込まれたユニットテストを実行します。ハードウェアの仕様にもよりますが、これには約5分ほどかかります。（省略可能ですが、推奨します）
|
||||
|
||||
$ ./rippled --unittest
|
||||
./rippled --unittest
|
||||
|
||||
0. `rippled`は、`rippled.cfg`構成ファイルの実行を必要とします。`rippled/cfg`に、サンプル構成ファイルの`rippled-example.cfg`があります。このファイルをコピーし、`rippled`を非ルートユーザーとして実行できる場所に`rippled.cfg`という名前で保存します。`rippled`ディレクトリーにアクセスして、以下を実行します。
|
||||
|
||||
$ mkdir -p $HOME/.config/ripple
|
||||
$ cp cfg/rippled-example.cfg $HOME/.config/ripple/rippled.cfg
|
||||
mkdir -p $HOME/.config/ripple
|
||||
cp cfg/rippled-example.cfg $HOME/.config/ripple/rippled.cfg
|
||||
|
||||
0. `rippled.cfg`を編集し、必要なファイルパスを設定します。`rippled`を実行するユーザーは、ここで指定するすべてのパスへの書き込み権限を持っている必要があります。
|
||||
|
||||
@@ -110,13 +110,13 @@ labels:
|
||||
|
||||
0. `rippled`は、`validators.txt`ファイルの実行を必要とします。`rippled/cfg/`に、サンプルバリデータファイルの`validators-example.txt`があります。このファイルをコピーし、`rippled.cfg`ファイルと同じフォルダーに`validators.txt`という名前で保存します。`rippled`ディレクトリーにアクセスして、以下を実行します。
|
||||
|
||||
$ cp cfg/validators-example.txt $HOME/.config/ripple/validators.txt
|
||||
cp cfg/validators-example.txt $HOME/.config/ripple/validators.txt
|
||||
|
||||
**警告:** `validators.txt`のファイルはあなたのサーバーがレジャーを検証する判断の為の設定を含まれています。 バリデータの設定に注意しない変更を加えると、サーバーがネットワークから分岐し、古い、不完全、または正しくないデータについて報告する原因となることがあります。そのようなデータを使用すると、経費の無駄になります。
|
||||
|
||||
0. ビルドディレクトリー（`my_build`など）にアクセスし、`rippled`サービスを開始します。
|
||||
|
||||
$ ./rippled
|
||||
./rippled
|
||||
|
||||
以下は、ターミナルに表示される内容の抜粋です。
|
||||
|
||||
|
||||
@@ -17,19 +17,19 @@ For development purposes, run `rippled` as a non-admin user, not using `sudo`.
|
||||
|
||||
0. Install Xcode command line tools.
|
||||
|
||||
$ xcode-select --install
|
||||
xcode-select --install
|
||||
|
||||
0. Install [Homebrew](https://brew.sh/).
|
||||
|
||||
$ ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
|
||||
ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
|
||||
|
||||
0. Update Homebrew.
|
||||
|
||||
$ brew update
|
||||
brew update
|
||||
|
||||
0. Use Homebrew to install dependencies.
|
||||
|
||||
$ brew install git cmake pkg-config protobuf openssl ninja
|
||||
brew install git cmake pkg-config protobuf openssl ninja
|
||||
|
||||
0. Install a compatible version of Boost. `rippled` 1.7.2 is compatible with Boost 1.75.0. To compile Boost yourself, complete the following steps:
|
||||
|
||||
@@ -39,9 +39,9 @@ For development purposes, run `rippled` as a non-admin user, not using `sudo`.
|
||||
|
||||
3. In a terminal, run:
|
||||
|
||||
$ cd /LOCATION/OF/YOUR/BOOST/DIRECTORY
|
||||
$ ./bootstrap.sh
|
||||
$ ./b2 cxxflags="-std=c++14"
|
||||
cd /LOCATION/OF/YOUR/BOOST/DIRECTORY
|
||||
./bootstrap.sh
|
||||
./b2 cxxflags="-std=c++14"
|
||||
|
||||
0. Ensure that your `BOOST_ROOT` environment points to the directory created by the Boost installation:
|
||||
|
||||
@@ -50,67 +50,67 @@ For development purposes, run `rippled` as a non-admin user, not using `sudo`.
|
||||
2. Edit the code below with your Boost directory location and run it to add Boost environment variable to your `.zshrc` or `.bash_profile` file so it's automatically set when you log in.
|
||||
|
||||
# for zsh
|
||||
$ echo "export BOOST_ROOT=/Users/my_user/boost_1_75_0" >> ~/.zshrc
|
||||
echo "export BOOST_ROOT=/Users/my_user/boost_1_75_0" >> ~/.zshrc
|
||||
# for bash
|
||||
$ echo "export BOOST_ROOT=/Users/my_user/boost_1_75_0" >> ~/.bash_profile
|
||||
echo "export BOOST_ROOT=/Users/my_user/boost_1_75_0" >> ~/.bash_profile
|
||||
|
||||
0. If you updated your `.bash_profile` file in the previous step, be sure to source it in a new Terminal window. For example:
|
||||
|
||||
# zsh
|
||||
$ source ~/.zshrc
|
||||
source ~/.zshrc
|
||||
# bash
|
||||
$ source ~/.bash_profile
|
||||
source ~/.bash_profile
|
||||
|
||||
0. Clone the `rippled` source code into your desired location and access the `rippled` directory. To do this, you'll need to set up Git (installed earlier using Homebrew) and GitHub. For example, you'll need to create a GitHub account and set up your SSH key. For more information, see [Set up git](https://docs.github.com/en/get-started/quickstart/set-up-git/).
|
||||
|
||||
$ git clone https://github.com/ripple/rippled.git
|
||||
$ cd rippled
|
||||
git clone https://github.com/ripple/rippled.git
|
||||
cd rippled
|
||||
|
||||
0. Switch to the appropriate branch for the software version you want:
|
||||
|
||||
For the latest stable release, use the `master` branch.
|
||||
|
||||
$ git checkout master
|
||||
git checkout master
|
||||
|
||||
For the latest release candidate, use the `release` branch:
|
||||
|
||||
$ git checkout release
|
||||
git checkout release
|
||||
|
||||
For the latest in-progress version, use the `develop` branch:
|
||||
|
||||
$ git checkout develop
|
||||
git checkout develop
|
||||
|
||||
Or, you can checkout one of the tagged releases listed on [GitHub](https://github.com/ripple/rippled/releases).
|
||||
|
||||
0. Check the commit log to be sure you're compiling the right code. The most recent commit should be signed by a well-known Ripple developer and should set the version number to the latest released version. The [release announcements for `rippled`](https://xrpl.org/blog/label/rippled-release-notes.html) generally show the exact commit to expect for that release.
|
||||
|
||||
$ git log -1
|
||||
git log -1
|
||||
|
||||
0. In the `rippled` directory you cloned, create your build directory and access it. For example:
|
||||
|
||||
$ mkdir my_build
|
||||
$ cd my_build
|
||||
mkdir my_build
|
||||
cd my_build
|
||||
|
||||
0. Build `rippled`. This could take about 5 minutes, depending on your hardware specs.
|
||||
|
||||
$ cmake -G "Unix Makefiles" -DCMAKE_BUILD_TYPE=Debug ..
|
||||
cmake -G "Unix Makefiles" -DCMAKE_BUILD_TYPE=Debug ..
|
||||
|
||||
You can set `CMAKE_BUILD_TYPE` to the `Debug` or `Release` build type. All four standard [`CMAKE_BUILD_TYPE`](https://cmake.org/cmake/help/v3.0/variable/CMAKE_BUILD_TYPE.html) values are supported.
|
||||
|
||||
0. Run the build using CMake. This could take about 10 minutes, depending on your hardware specs.
|
||||
|
||||
$ cmake --build . -- -j 4
|
||||
cmake --build . -- -j 4
|
||||
|
||||
**Tip:** This example uses a `-j` parameter set to `4`, which uses four processes to build in parallel. The best number of processes to use depends on how many CPU cores your hardware has available. Use `sysctl -n hw.ncpu` to get your CPU core count.
|
||||
|
||||
0. Run unit tests built into the server executable. This could take about 5 minutes, depending on your hardware specs. (optional, but recommended)
|
||||
|
||||
$ ./rippled --unittest
|
||||
./rippled --unittest
|
||||
|
||||
0. `rippled` requires the `rippled.cfg` config file to run. You can find an example config file, `rippled-example.cfg` in `rippled/cfg`. Make a copy and save it as `rippled.cfg` in a location that enables you to run `rippled` as a non-root user. Access the `rippled` directory and run:
|
||||
|
||||
$ mkdir -p $HOME/.config/ripple
|
||||
$ cp cfg/rippled-example.cfg $HOME/.config/ripple/rippled.cfg
|
||||
mkdir -p $HOME/.config/ripple
|
||||
cp cfg/rippled-example.cfg $HOME/.config/ripple/rippled.cfg
|
||||
|
||||
0. Edit `rippled.cfg` to set necessary file paths. The user you plan to run `rippled` as must have write permissions to all of the paths you specify here.
|
||||
|
||||
@@ -124,13 +124,13 @@ For development purposes, run `rippled` as a non-admin user, not using `sudo`.
|
||||
|
||||
0. `rippled` requires the `validators.txt` file to run. You can find an example validators file, `validators-example.txt`, in `rippled/cfg/`. Make a copy and save it as `validators.txt` in the same folder as your `rippled.cfg` file. Access the `rippled` directory and run:
|
||||
|
||||
$ cp cfg/validators-example.txt $HOME/.config/ripple/validators.txt
|
||||
cp cfg/validators-example.txt $HOME/.config/ripple/validators.txt
|
||||
|
||||
**Warning:** The `validators.txt` file contains settings that determine how your server declares a ledger to be validated. If you are not careful, changes to this file could cause your server to diverge from the rest of the network and report out of date, incomplete, or inaccurate data. Acting on such data can cause you to lose money.
|
||||
|
||||
0. Access your build directory, `my_build` for example, and start the `rippled` service.
|
||||
|
||||
$ ./rippled
|
||||
./rippled
|
||||
|
||||
Here's an excerpt of what you can expect to see in your terminal:
|
||||
|
||||
|
||||
@@ -16,7 +16,7 @@ A `rippled` server should run comfortably on commodity hardware, to make it inex
|
||||
- Development: Mac OS X, Windows (64-bit), or most Linux distributions
|
||||
- CPU: 64-bit x86_64, 2+ cores
|
||||
- Disk: Minimum 50 GB for the database partition. SSD strongly recommended (minimum 1000 IOPS, more is better)
|
||||
- RAM: 8 GB+
|
||||
- RAM: 16 GB+
|
||||
|
||||
<!-- SPELLING_IGNORE: iops, ntp, x86_64, ec2 -->
|
||||
|
||||
@@ -25,12 +25,12 @@ Amazon EC2's `m3.large` VM size may be appropriate depending on your workload. A
|
||||
|
||||
## Recommended Specifications
|
||||
|
||||
For best performance in enterprise production environments, Ripple recommends running `rippled` on bare metal with the following characteristics:
|
||||
For best performance in enterprise production environments, it is recommended to run `rippled` on bare metal with the following characteristics:
|
||||
|
||||
- Operating System: Ubuntu (LTS) or CentOS or RedHat Enterprise Linux (latest release)
|
||||
- CPU: Intel Xeon 3+ GHz processor with 4 cores and hyperthreading enabled
|
||||
- Disk: SSD (10,000 IOPS or better)
|
||||
- RAM: 32 GB
|
||||
- CPU: Intel Xeon 3+ GHz processor with 8 cores and hyperthreading enabled
|
||||
- Disk: SSD / NVMe(10,000 IOPS or better)
|
||||
- RAM: 64 GB
|
||||
- Network: Enterprise data center network with a gigabit network interface on the host
|
||||
|
||||
## System Time
|
||||
|
||||
@@ -361,7 +361,7 @@ Escrowトランザクションでは、関係する送金元の所有者準備
|
||||
|
||||
Payment Channelの作成時に、LedgerEntryTypeが`PayChannel`の`CreatedNode`を探します。また、送金元の残高の減少を示す、LedgerEntryTypeが`AccountRoot`の`ModifiedNode`も探す必要があります。アドレスが送金元に一致することを確認するために`FinalFields`の`Account`フィールドを探し、XRP残高の変化を確認するために`Balance`フィールドの差異を確認します。
|
||||
|
||||
[fixPayChanRecipientOwnerDir Amendment](known-amendments.html#fixpaychanrecipientownerdir) :not_enabled: が有効な場合は、メタデータは宛先のアカウントの[所有者ディレクトリー](directorynode.html)を変更して、新しく作成されるPayment Channelをリストで示す必要もあります。これにより、アカウントがオープンPayment Channelの受取人である場合に、そのアカウントが[削除される](accounts.html#アカウントの削除)ことを防ぎます。（fixPayChanRecipientOwnerDir Amendmentが有効になる前にPayment Channelが作成された場合は、アカウントを削除できます。）
|
||||
[fixPayChanRecipientOwnerDir Amendment](known-amendments.html#fixpaychanrecipientownerdir)が有効な場合は、メタデータは宛先のアカウントの[所有者ディレクトリー](directorynode.html)を変更して、新しく作成されるPayment Channelをリストで示す必要もあります。これにより、アカウントがオープンPayment Channelの受取人である場合に、そのアカウントが[削除される](accounts.html#アカウントの削除)ことを防ぎます。（fixPayChanRecipientOwnerDir Amendmentが有効になる前にPayment Channelが作成された場合は、アカウントを削除できます。）
|
||||
|
||||
Payment Channelの閉鎖を要求する方法は、Payment Channelの不変の`CancelAfter`時刻（作成時にのみ設定されます）以外にもいくつかあります。トランザクションでChannelの閉鎖をスケジュールする場合は、そのChannel用にLedgerEntryTypeが`PayChannel`の`ModifiedNode`エントリーがあり、`FinalFields`の`Expiration`フィールドには閉鎖時刻が新たに追加されています。以下の例は、送金元がクレームを清算せずにChannelを閉鎖するよう要求した場合に`PayChannel`に対して行われる変更を示します。
|
||||
|
||||
|
||||
Reference in New Issue
Block a user