mirror of
https://github.com/XRPLF/xrpl-dev-portal.git
synced 2025-11-14 08:45:50 +00:00
Rome Reginelli
File diff suppressed because one or more lines are too long
58
assets/css/fonts-ja.css
Normal file
58
assets/css/fonts-ja.css
Normal file
@@ -0,0 +1,58 @@
|
||||
/*
|
||||
"Makinas" free font by Mojiwaku Kenkyuu.
|
||||
もじワク研究からの「マキナス」フォント
|
||||
https://moji-waku.com/makinas/index.html
|
||||
*/
|
||||
@font-face {
|
||||
font-family: 'Makinas-4-Flat';
|
||||
font-style: normal;
|
||||
font-weight: 400;
|
||||
font-display: swap;
|
||||
src: url("../font/Makinas-4-Flat.otf") format('opentype');
|
||||
unicode-range: U+20, U+3001-303f, U+30A0-30fe, U+4e00-9faf, U+ff00-ffef; /* omit hiragana */
|
||||
}
|
||||
|
||||
@font-face {
|
||||
font-family: 'Makinas-4-Square';
|
||||
font-style: normal;
|
||||
font-weight: 400;
|
||||
font-display: swap;
|
||||
src: url("../font/Makinas-4-Square.otf") format('opentype');
|
||||
unicode-range: U+3040-309F; /* hiragana only */
|
||||
}
|
||||
|
||||
|
||||
/* Other Japanese fonts unused for now */
|
||||
/*
|
||||
851ゴチカクット フォント (http://pm85122.onamae.jp/851Gkktt.html から)
|
||||
作成者の8:51:22pmさんに感謝
|
||||
|
||||
@font-face {
|
||||
font-family: '851Gkktt';
|
||||
font-style: normal;
|
||||
font-weight: 700;
|
||||
font-display: swap;
|
||||
src: url("../font/851Gkktt_005.ttf") format('truetype');
|
||||
unicode-range: U+20, U+3001-30fe, U+4e00-9faf, U+ff00-ffef;
|
||||
}
|
||||
|
||||
|
||||
/* M+ 1p from Google Fonts (unicode range simplified a bit)
|
||||
@font-face {
|
||||
font-family: 'M PLUS 1p';
|
||||
font-style: normal;
|
||||
font-weight: 400;
|
||||
font-display: swap;
|
||||
src: local('M PLUS 1p'), local('MPLUS1p-Regular'), url(https://fonts.gstatic.com/s/mplus1p/v19/e3tjeuShHdiFyPFzBRro_VYUcXm4y4YtjOJGYMp5iAw4B3f5iUc.0.woff2) format('woff2');
|
||||
unicode-range: U+20, U+3001-30fe, U+4e00-9faf, U+ff00-ffef;
|
||||
}
|
||||
|
||||
@font-face {
|
||||
font-family: 'M PLUS 1p';
|
||||
font-style: normal;
|
||||
font-weight: 700;
|
||||
font-display: swap;
|
||||
src: local('M PLUS 1p Bold'), local('MPLUS1p-Bold'), url(https://fonts.gstatic.com/s/mplus1p/v19/e3tmeuShHdiFyPFzBRrQRBEgfivGoOYmg_dUa_BuiDU9F33s7CtHVU4.0.woff2) format('woff2');
|
||||
unicode-range: U+20, U+3001-30fe, U+4e00-9faf, U+ff00-ffef;
|
||||
}
|
||||
*/
|
||||
BIN
assets/font/Makinas-4-Flat.otf
Normal file
BIN
assets/font/Makinas-4-Flat.otf
Normal file
Binary file not shown.
BIN
assets/font/Makinas-4-Square.otf
Normal file
BIN
assets/font/Makinas-4-Square.otf
Normal file
Binary file not shown.
115
assets/img/icon-language-selector.svg
Normal file
115
assets/img/icon-language-selector.svg
Normal file
@@ -0,0 +1,115 @@
|
||||
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
|
||||
<!-- Created with Inkscape (http://www.inkscape.org/) -->
|
||||
|
||||
<svg
|
||||
xmlns:dc="http://purl.org/dc/elements/1.1/"
|
||||
xmlns:cc="http://creativecommons.org/ns#"
|
||||
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
|
||||
xmlns:svg="http://www.w3.org/2000/svg"
|
||||
xmlns="http://www.w3.org/2000/svg"
|
||||
xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
|
||||
xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
|
||||
version="1.1"
|
||||
id="svg2"
|
||||
xml:space="preserve"
|
||||
width="3214.9468"
|
||||
height="3725.3333"
|
||||
viewBox="0 0 3214.9468 3725.3333"
|
||||
sodipodi:docname="icon-language-selector.svg"
|
||||
inkscape:version="0.92.4 5da689c313, 2019-01-14"><metadata
|
||||
id="metadata8"><rdf:RDF><cc:Work
|
||||
rdf:about=""><dc:format>image/svg+xml</dc:format><dc:type
|
||||
rdf:resource="http://purl.org/dc/dcmitype/StillImage" /><dc:title></dc:title></cc:Work></rdf:RDF></metadata><defs
|
||||
id="defs6" /><sodipodi:namedview
|
||||
pagecolor="#ffffff"
|
||||
bordercolor="#666666"
|
||||
borderopacity="1"
|
||||
objecttolerance="10"
|
||||
gridtolerance="10"
|
||||
guidetolerance="10"
|
||||
inkscape:pageopacity="0"
|
||||
inkscape:pageshadow="2"
|
||||
inkscape:window-width="1920"
|
||||
inkscape:window-height="1024"
|
||||
id="namedview4"
|
||||
showgrid="false"
|
||||
inkscape:pagecheckerboard="true"
|
||||
inkscape:zoom="0.063350037"
|
||||
inkscape:cx="1670.6146"
|
||||
inkscape:cy="1862.6666"
|
||||
inkscape:window-x="0"
|
||||
inkscape:window-y="1"
|
||||
inkscape:window-maximized="1"
|
||||
inkscape:current-layer="g10" /><g
|
||||
id="g10"
|
||||
inkscape:groupmode="layer"
|
||||
inkscape:label="ink_ext_XXXXXX"
|
||||
transform="matrix(1.3333333,0,0,-1.3333333,0,3725.3333)"><g
|
||||
id="g12"
|
||||
transform="scale(0.1)"><g
|
||||
id="g14"
|
||||
transform="scale(1.69573)"><path
|
||||
d="M 7103.55,14358.7 1603.03,16300 V 4328.22 l 5500.52,1779.59 v 8250.89"
|
||||
style="fill:#040606;fill-opacity:1;fill-rule:nonzero;stroke:none"
|
||||
id="path16"
|
||||
inkscape:connector-curvature="0" /></g><g
|
||||
id="g18"
|
||||
transform="scale(1.69635)"><path
|
||||
d="M 6968.96,14359.4 12678,16300 V 4332.6 L 6968.96,6111.53 v 8247.87"
|
||||
style="fill:#ffffff;fill-opacity:1;fill-rule:nonzero;stroke:none"
|
||||
id="path20"
|
||||
inkscape:connector-curvature="0" /></g><g
|
||||
id="g22"
|
||||
transform="scale(1.49453)"><path
|
||||
d="M 200.466,2533.04 7910.06,5102.75 V 16300 L 200.466,13730.3 V 2533.04"
|
||||
style="fill:#ffffff;fill-opacity:1;fill-rule:nonzero;stroke:none"
|
||||
id="path24"
|
||||
inkscape:connector-curvature="0" /></g><g
|
||||
id="g26"
|
||||
transform="scale(1.20038)"><path
|
||||
d="M 14222.2,2943.15 15582.6,705.027 16300,2784.12 14222.2,2943.15"
|
||||
style="fill:#040606;fill-opacity:1;fill-rule:nonzero;stroke:none"
|
||||
id="path28"
|
||||
inkscape:connector-curvature="0" /></g><g
|
||||
id="g30"
|
||||
transform="scale(1.16442)"><path
|
||||
d="m 3621.88,15967.1 c -52.56,51.6 68.45,-421.7 236.85,-592 298.61,-301.3 531.85,-340.1 656.04,-345.1 274.81,-11 613.95,68.5 815.34,152.9 194.86,83.1 536.31,257.4 665.56,511.7 27.4,54.4 102.2,145.7 55.22,371.2 -35.64,173.5 -146.08,234.2 -280.74,224.6 -134.66,-9.1 -542.33,-117.8 -739.51,-178.5 -197.26,-59.8 -603.56,-183.5 -780.64,-221.9 -176.65,-38.3 -566.12,17.8 -628.12,77.1"
|
||||
style="fill:#040606;fill-opacity:1;fill-rule:nonzero;stroke:none"
|
||||
id="path32"
|
||||
inkscape:connector-curvature="0" /></g><g
|
||||
id="g34"
|
||||
transform="scale(1.0917)"><path
|
||||
d="m 9188.43,10995.1 c -83.18,30.2 -1803.98,743 -2047.91,859.8 -199.6,96 -689.02,302.9 -919.3,396.9 648.62,1000.1 1058.07,1754.8 1112.58,1869.8 100.85,210.3 787.39,1553.7 803.42,1636.4 15.57,83.8 35.08,393.4 19.97,467 -15.11,75 -266.83,-69.2 -608.59,-185.1 -342.31,-115.4 -992.86,-538.5 -1244.12,-591.5 -252.17,-52.6 -1058.07,-357.9 -1470.46,-494.7 -412.38,-136.9 -1192.45,-375 -1513.33,-461.6 -321.33,-86.7 -601.81,-93.5 -781.53,-148 0,0 23.91,-251.8 71.63,-327.2 47.18,-75.5 217.19,-260.5 414.86,-312.2 197.67,-52 524.87,-31.2 673.9,2.9 148.95,34.6 406.98,160.7 441.61,215.7 34.99,56 -18.05,228.4 40.85,280.5 59.45,51.6 844.83,235.2 1141.34,324.7 296.51,91.2 1431.53,482.1 1585.42,462.2 C 6860.04,14829 5947.06,13020.6 5653.02,12481.1 5358.89,11941.7 3650.37,9568.39 3286.62,9150.14 3010.54,8832.19 2341.49,8018.6 2109.74,7835.03 c 58.44,-16.12 472.75,19.42 548.23,66.14 470.36,289.73 1253.82,1265 1506.09,1562.06 749.84,879.37 1408.63,1803.07 1931.02,2595.77 h 0.56 c 101.76,-42.4 924.61,-712.8 1139.32,-861.4 214.71,-148.5 1062.01,-621.2 1245.58,-699.7 183.57,-79.4 889.07,-404.6 918.75,-294.5 29.68,111 -127.6,760.1 -210.86,791.7"
|
||||
style="fill:#040606;fill-opacity:1;fill-rule:nonzero;stroke:none"
|
||||
id="path36"
|
||||
inkscape:connector-curvature="0" /></g><g
|
||||
id="g38"
|
||||
transform="scale(1.12147)"><path
|
||||
d="m 5073.69,1979.54 c 160.5,-98.08 312.09,-178.34 481.51,-258.59 338.84,-169.42 722.26,-347.76 1087.85,-481.51 499.35,-187.25 998.69,-338.838 1498.03,-454.757 276.43,-62.418 579.6,-115.919 873.85,-160.504 26.76,0 820.35,-98.085 980.86,-98.085 h 802.51 c 312.1,26.751 606.4,44.584 918.4,89.169 249.7,35.667 526.1,80.251 793.6,142.669 196.2,44.584 401.3,89.169 597.5,151.587 187.2,53.501 401.2,124.831 606.3,196.171 133.8,44.58 276.4,107 419.1,160.5 115.9,53.5 258.6,115.92 392.3,169.42 160.6,71.34 347.8,169.42 526.1,258.59 142.7,71.34 303.2,160.5 454.8,249.67 115.9,62.42 383.4,267.51 526.1,267.51 160.5,0 267.5,-142.67 267.5,-267.51 0,-258.59 -347.8,-338.84 -508.3,-454.76 -169.4,-115.92 -374.5,-205.08 -552.8,-303.17 -356.7,-187.253 -722.3,-347.756 -1070,-481.509 -454.8,-169.42 -954.1,-329.923 -1400,-436.926 -169.4,-35.667 -338.8,-80.251 -508.2,-107.002 C 12171.5,142.67 11244.1,0 10985.6,0 H 9808.53 c -312.09,26.7505 -642.01,62.4179 -954.1,107.002 -276.42,44.584 -570.68,98.086 -847.1,160.503 -214,44.585 -445.84,107.003 -650.93,169.421 -356.67,98.085 -704.43,222.921 -1043.27,356.674 -615.26,231.84 -1257.28,535.01 -1863.62,936.27 -107,71.33 -115.92,142.67 -115.92,222.92 0,133.75 98.08,258.59 258.59,258.59 142.67,0 428.01,-205.09 481.51,-231.84"
|
||||
style="fill:#040606;fill-opacity:1;fill-rule:evenodd;stroke:none"
|
||||
id="path40"
|
||||
inkscape:connector-curvature="0" /></g><g
|
||||
id="g42"
|
||||
transform="scale(1.51227)"><path
|
||||
d="M 8014.44,16134.7 V 5025.56 c -6.61,-33.07 -19.84,-66.13 -46.29,-99.19 -13.22,-19.84 -39.67,-46.29 -59.51,-52.9 C 7743.33,4807.34 297.566,2307.79 198.377,2307.79 c -79.351,0 -152.089,52.9 -191.76442,138.86 0,6.62 -6.61258,13.23 -6.61258,26.45 v 11115.7 c 13.2252,33.1 19.8377,79.4 46.288,105.8 52.9006,72.8 145.477,86 204.99,105.8 112.414,39.7 7445.762,2499.6 7551.562,2499.6 66.13,0 211.6,-46.3 211.6,-165.3 z M 7611.07,5190.87 403.367,2790.51 V 13423.5 L 7611.07,15823.9 V 5190.87"
|
||||
style="fill:#040606;fill-opacity:1;fill-rule:evenodd;stroke:none"
|
||||
id="path44"
|
||||
inkscape:connector-curvature="0" /></g><g
|
||||
id="g46"
|
||||
transform="scale(1.71411)"><path
|
||||
d="M 12723.8,16113.3 V 4311.27 c -5.8,-134.18 -99.2,-192.52 -186.7,-192.52 -75.8,0 -624.2,186.69 -717.6,215.86 -735,227.52 -1475.9,455.05 -2205.18,682.57 -163.35,52.51 -332.54,105.01 -490.05,157.52 -140.02,40.83 -291.7,87.5 -431.71,134.18 -624.23,192.52 -1260.13,385.04 -1884.36,595.06 -23.34,5.83 -81.68,87.51 -81.68,105.01 v 8243.35 c 11.67,29.2 23.34,64.2 52.51,87.5 46.67,52.5 2047.71,717.6 2835.29,980.1 210.02,75.8 2841.08,980.1 2922.78,980.1 105,0 186.7,-75.8 186.7,-186.7 z M 12367.9,4532.96 7076.56,6178.13 V 14083.1 L 12367.9,15880 V 4532.96"
|
||||
style="fill:#040606;fill-opacity:1;fill-rule:evenodd;stroke:none"
|
||||
id="path48"
|
||||
inkscape:connector-curvature="0" /></g><g
|
||||
id="g50"
|
||||
transform="scale(1.48515)"><path
|
||||
d="M 16235.4,2378.81 8076.61,4979.28 8110.74,16300 16235.4,13714.1 V 2378.81"
|
||||
style="fill:#040606;fill-opacity:1;fill-rule:nonzero;stroke:none"
|
||||
id="path52"
|
||||
inkscape:connector-curvature="0" /></g><g
|
||||
id="g54"
|
||||
transform="scale(1.33098)"><path
|
||||
d="m 12990.3,14581.8 1172.9,-355.3 2136.8,-7701.24 -1204.8,365.52 -432.8,1581.01 -2489.7,754.63 -535.4,-1287.92 -1205.1,365.6 z m 536.2,-2038.8 -893.6,-2159.8 1642.8,-497.94 -749.2,2657.74"
|
||||
style="fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:none"
|
||||
id="path56"
|
||||
inkscape:connector-curvature="0" /></g></g></g></svg>
|
||||
|
After Width: | Height: | Size: 8.4 KiB |
@@ -1,30 +1,48 @@
|
||||
<!--{# Links within the dev portal #}-->
|
||||
[Address]: basic-data-types.html#addresses
|
||||
[アドレス]: basic-data-types.html#アドレス
|
||||
[admin command]: admin-rippled-methods.html
|
||||
[base58]: base58-encodings.html
|
||||
[common fields]: transaction-common-fields.html
|
||||
[Currency Amount]: basic-data-types.html#specifying-currency-amounts
|
||||
[通貨額]: basic-data-types.html#通貨額の指定
|
||||
[通貨額の指定]: basic-data-types.html#通貨額の指定
|
||||
[Currency Code]: currency-formats.html#currency-codes
|
||||
[通貨コード]: currency-formats.html#通貨コード
|
||||
[drops of XRP]: basic-data-types.html#specifying-currency-amounts
|
||||
[fee levels]: transaction-cost.html#fee-levels
|
||||
[XRPのdrop数]: basic-data-types.html#通貨額の指定
|
||||
[Hash]: basic-data-types.html#hashes
|
||||
[ハッシュ]: basic-data-types.html#ハッシュ
|
||||
[identifying hash]: transaction-basics.html#identifying-transactions
|
||||
[Internal Type]: serialization.html
|
||||
[内部の型]: serialization.html
|
||||
[Ledger Index]: basic-data-types.html#ledger-index
|
||||
[レジャーインデックス]: basic-data-types.html#レジャーインデックス
|
||||
[ledger format]: ledger-data-formats.html
|
||||
[Marker]: markers-and-pagination.html
|
||||
[マーカー]: markers-and-pagination.html
|
||||
[result code]: transaction-results.html
|
||||
[seconds since the Ripple Epoch]: basic-data-types.html#specifying-time
|
||||
[Rippleエポック以降の経過秒数]: basic-data-types.html#時間の指定
|
||||
[Sequence Number]: basic-data-types.html#account-sequence
|
||||
[シーケンス番号]: basic-data-types.html#アカウントシーケンス
|
||||
[SHA-512Half]: basic-data-types.html#hashes
|
||||
[SHA-512ハーフ]: basic-data-types.html#ハッシュ
|
||||
[Specifying Currency Amounts]: basic-data-types.html#specifying-currency-amounts
|
||||
[Specifying Ledgers]: basic-data-types.html#specifying-ledgers
|
||||
[レジャーの指定]: basic-data-types.html#レジャーの指定
|
||||
[Specifying Time]: basic-data-types.html#specifying-time
|
||||
[時間の指定]: basic-data-types.html#時間の指定
|
||||
[standard format]: response-formatting.html
|
||||
[標準フォーマット]: response-formatting.html
|
||||
[Transaction Cost]: transaction-cost.html
|
||||
[transaction cost]: transaction-cost.html
|
||||
[トランザクションコスト]: transaction-cost.html
|
||||
[universal error types]: error-formatting.html#universal-errors
|
||||
[汎用エラータイプ]: error-formatting.html#汎用エラー
|
||||
[XRP, in drops]: basic-data-types.html#specifying-currency-amounts
|
||||
[XRP、drop単位]: basic-data-types.html#通貨額の指定
|
||||
|
||||
<!-- API object types -->
|
||||
[AccountRoot object]: accountroot.html
|
||||
@@ -101,6 +119,9 @@
|
||||
{% for method in api_methods %}
|
||||
[{{method}} method]: {{method|lower}}.html
|
||||
[{{method}} command]: {{method|lower}}.html
|
||||
{% if target.lang == "ja" %}
|
||||
[{{method}}メソッド]: {{method|lower}}.html
|
||||
{% endif %}
|
||||
{% endfor %}
|
||||
|
||||
<!--{# Amendment links #}-->
|
||||
|
||||
@@ -1,38 +1,49 @@
|
||||
<!-- rippled release notes links -->
|
||||
|
||||
[New in: rippled 0.26.0]: https://github.com/ripple/rippled/releases/tag/0.26.0 "BADGE_BLUE"
|
||||
[New in: rippled 0.26.1]: https://github.com/ripple/rippled/releases/tag/0.26.1 "BADGE_BLUE"
|
||||
[New in: rippled 0.26.2]: https://github.com/ripple/rippled/releases/tag/0.26.2 "BADGE_BLUE"
|
||||
[New in: rippled 0.26.3-sp1]: https://github.com/ripple/rippled/releases/tag/0.26.3-sp1 "BADGE_BLUE"
|
||||
[New in: rippled 0.26.4]: https://github.com/ripple/rippled/releases/tag/0.26.4 "BADGE_BLUE"
|
||||
[New in: rippled 0.26.4-sp1]: https://github.com/ripple/rippled/releases/tag/0.26.4-sp1 "BADGE_BLUE"
|
||||
[New in: rippled 0.27.0]: https://github.com/ripple/rippled/releases/tag/0.27.0 "BADGE_BLUE"
|
||||
[New in: rippled 0.27.1]: https://github.com/ripple/rippled/releases/tag/0.27.1 "BADGE_BLUE"
|
||||
[New in: rippled 0.27.2]: https://github.com/ripple/rippled/releases/tag/0.27.2 "BADGE_BLUE"
|
||||
[New in: rippled 0.27.3]: https://github.com/ripple/rippled/releases/tag/0.27.3 "BADGE_BLUE"
|
||||
[New in: rippled 0.27.3-sp1]: https://github.com/ripple/rippled/releases/tag/0.27.3-sp1 "BADGE_BLUE"
|
||||
[New in: rippled 0.27.3-sp2]: https://github.com/ripple/rippled/releases/tag/0.27.3-sp2 "BADGE_BLUE"
|
||||
[New in: rippled 0.27.4]: https://github.com/ripple/rippled/releases/tag/0.27.4 "BADGE_BLUE"
|
||||
[New in: rippled 0.28.0]: https://github.com/ripple/rippled/releases/tag/0.28.0 "BADGE_BLUE"
|
||||
[Removed in: rippled 0.28.0]: https://github.com/ripple/rippled/releases/tag/0.28.0 "BADGE_RED"
|
||||
[New in: rippled 0.28.2]: https://github.com/ripple/rippled/releases/tag/0.28.2 "BADGE_BLUE"
|
||||
[New in: rippled 0.29.0]: https://github.com/ripple/rippled/releases/tag/0.29.0 "BADGE_BLUE"
|
||||
[New in: rippled 0.29.0-hf1]: https://github.com/ripple/rippled/releases/tag/0.29.0-hf1 "BADGE_BLUE"
|
||||
[New in: rippled 0.30.0]: https://github.com/ripple/rippled/releases/tag/0.30.0 "BADGE_BLUE"
|
||||
[New in: rippled 0.30.1]: https://github.com/ripple/rippled/releases/tag/0.30.1 "BADGE_BLUE"
|
||||
[New in: rippled 0.31.0]: https://github.com/ripple/rippled/releases/tag/0.31.0 "BADGE_BLUE"
|
||||
[New in: rippled 0.32.0]: https://github.com/ripple/rippled/releases/tag/0.32.0 "BADGE_BLUE"
|
||||
[New in: rippled 0.32.0]: https://github.com/ripple/rippled/releases/tag/0.32.0 "BADGE_BLUE"
|
||||
[New in: rippled 0.32.1]: https://github.com/ripple/rippled/releases/tag/0.32.1 "BADGE_BLUE"
|
||||
[New in: rippled 0.33.0]: https://github.com/ripple/rippled/releases/tag/0.33.0 "BADGE_BLUE"
|
||||
[New in: rippled 0.50.0]: https://github.com/ripple/rippled/releases/tag/0.50.0 "BADGE_BLUE"
|
||||
[New in: rippled 0.70.0]: https://github.com/ripple/rippled/releases/tag/0.70.0 "BADGE_BLUE"
|
||||
[New in: rippled 0.70.2]: https://github.com/ripple/rippled/releases/tag/0.70.2 "BADGE_BLUE"
|
||||
[New in: rippled 0.80.0]: https://github.com/ripple/rippled/releases/tag/0.80.0 "BADGE_BLUE"
|
||||
[New in: rippled 0.80.1]: https://github.com/ripple/rippled/releases/tag/0.80.1 "BADGE_BLUE"
|
||||
[New in: rippled 0.90.0]: https://github.com/ripple/rippled/releases/tag/0.90.0 "BADGE_BLUE"
|
||||
[New in: rippled 1.0.0]: https://github.com/ripple/rippled/releases/tag/1.0.0 "BADGE_BLUE"
|
||||
[New in: rippled 1.1.0]: https://github.com/ripple/rippled/releases/tag/1.1.0 "BADGE_BLUE"
|
||||
[New in: rippled 1.2.0]: https://github.com/ripple/rippled/releases/tag/1.2.0 "BADGE_BLUE"
|
||||
[New in: rippled 1.2.1]: https://github.com/ripple/rippled/releases/tag/1.2.1 "BADGE_BLUE"
|
||||
[New in: rippled 1.3.1]: https://github.com/ripple/rippled/releases/tag/1.3.1 "BADGE_BLUE"
|
||||
{% set rippled_versions = [
|
||||
"0.26.0",
|
||||
"0.26.1",
|
||||
"0.26.2",
|
||||
"0.26.3-sp1",
|
||||
"0.26.4",
|
||||
"0.26.4-sp1",
|
||||
"0.27.0",
|
||||
"0.27.1",
|
||||
"0.27.2",
|
||||
"0.27.3",
|
||||
"0.27.3-sp1",
|
||||
"0.27.3-sp2",
|
||||
"0.27.4",
|
||||
"0.28.0",
|
||||
"0.28.2",
|
||||
"0.29.0",
|
||||
"0.29.0-hf1",
|
||||
"0.30.0",
|
||||
"0.30.1",
|
||||
"0.31.0",
|
||||
"0.32.0",
|
||||
"0.32.1",
|
||||
"0.33.0",
|
||||
"0.50.0",
|
||||
"0.70.0",
|
||||
"0.70.2",
|
||||
"0.80.0",
|
||||
"0.80.1",
|
||||
"0.90.0",
|
||||
"1.0.0",
|
||||
"1.1.0",
|
||||
"1.2.0",
|
||||
"1.2.1",
|
||||
"1.3.1",
|
||||
] %}
|
||||
|
||||
{% for v in rippled_versions %}
|
||||
[New in: rippled {{v}}]: https://github.com/ripple/rippled/releases/tag/{{v}} "BADGE_BLUE"
|
||||
[Introduced in: rippled {{v}}]: https://github.com/ripple/rippled/releases/tag/{{v}} "BADGE_BLUE"
|
||||
[Updated in: rippled {{v}}]: https://github.com/ripple/rippled/releases/tag/{{v}} "BADGE_BLUE"
|
||||
[Removed in: rippled {{v}}]: https://github.com/ripple/rippled/releases/tag/{{v}} "BADGE_RED"
|
||||
[導入: rippled {{v}}]: https://github.com/ripple/rippled/releases/tag/{{v}} "BADGE_BLUE"
|
||||
[新規: rippled {{v}}]: https://github.com/ripple/rippled/releases/tag/{{v}} "BADGE_BLUE"
|
||||
[更新: rippled {{v}}]: https://github.com/ripple/rippled/releases/tag/{{v}} "BADGE_BLUE"
|
||||
[削除: rippled {{v}}]: https://github.com/ripple/rippled/releases/tag/{{v}} "BADGE_RED"
|
||||
{% endfor %}
|
||||
|
||||
@@ -4,4 +4,4 @@
|
||||
| `DeliveredAmount` | [Currency Amount][] | _(May be omitted)_ For a [partial payment](partial-payments.html), this field records the amount of currency actually delivered to the destination. To avoid errors when reading transactions, instead use the `delivered_amount` field, which is provided for all Payment transactions, partial or not. |
|
||||
| `TransactionIndex` | Unsigned Integer | The transaction's position within the ledger that included it. This is zero-indexed. (For example, the value `2` means it was the 3rd transaction in that ledger.) |
|
||||
| `TransactionResult` | String | A [result code](transaction-results.html) indicating whether the transaction succeeded or how it failed. |
|
||||
| [`delivered_amount`](transaction-metadata.html#delivered-amount) | [Currency Amount][] | _(Omitted for non-Payment transactions)_ The [Currency Amount][] actually received by the `Destination` account. Use this field to determine how much was delivered, regardless of whether the transaction is a [partial payment](partial-payments.html). See [this description](transaction-metadata.html#delivered-amount) for details. [New in: rippled 0.27.0][] |
|
||||
| [`delivered_amount`](transaction-metadata.html#delivered_amount) | [Currency Amount][] | _(Omitted for non-Payment transactions)_ The [Currency Amount][] actually received by the `Destination` account. Use this field to determine how much was delivered, regardless of whether the transaction is a [partial payment](partial-payments.html). See [this description](transaction-metadata.html#delivered_amount) for details. [New in: rippled 0.27.0][] |
|
||||
|
||||
@@ -27,6 +27,9 @@
|
||||
[{{tx}}]: {{tx|lower}}.html
|
||||
[{{tx}} transaction]: {{tx|lower}}.html
|
||||
[{{tx}} transactions]: {{tx|lower}}.html
|
||||
{% if target.lang == "ja" %}
|
||||
[{{tx}}トランザクション]: {{tx|lower}}.html
|
||||
{% endif %}
|
||||
{% endfor %}
|
||||
|
||||
{% for tx in pstxtypes %}
|
||||
|
||||
@@ -0,0 +1,16 @@
|
||||
# トランザクションの取消しについて
|
||||
|
||||
XRP Ledgerの重要かつ意図的な機能の1つに、トランザクションが検証済みレジャーに組み込まれると、即時に最終的なトランザクションになるという機能があります。
|
||||
|
||||
ただし、検証済みレジャーにまだ記録されていないトランザクションは、無効に設定することで実質的に取り消すことができます。通常は、同じアカウントから同じ`Sequence`値を指定した別のトランザクションを送信することになります。置換トランザクションが何もしないようにしたい場合は、オプションを指定せずに[AccountSetトランザクション][]を送信します。
|
||||
|
||||
たとえば、シーケンス番号が11、12、13の3つのトランザクションを送信しようとしたときに、トランザクション11が何らかの理由で失われるか、またはトランザクション11にネットワークに伝達するのに十分な[トランザクションコスト](transaction-cost.html)がない場合には、オプションを指定せずシーケンス番号11を指定したAccuontSetトランザクションを送信すれば、トランザクション11を取り消せます。このトランザクションは（新しいトランザクション11のトランザクションコストを消却する以外は）何も行いませんが、トランザクション12と13を有効にできます。
|
||||
|
||||
この方法により、異なるシーケンス番号のトランザクションの内容が実質的に重複することを防げるため、トランザクション12と13の番号を変更して再送信するよりも望ましい方法です。
|
||||
|
||||
つまり、オプションが指定されていないAccountSetトランザクションは標準的な「[no-op](http://en.wikipedia.org/wiki/NOP)」トランザクションです。
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
238
content/concepts/consensus-network/amendments/amendments.ja.md
Normal file
238
content/concepts/consensus-network/amendments/amendments.ja.md
Normal file
@@ -0,0 +1,238 @@
|
||||
# Amendment
|
||||
|
||||
[導入: rippled 0.31.0][]
|
||||
|
||||
Amendmentシステムは、混乱を生じさせることなく、分散型のXRP Ledgerネットワークに新しい機能を導入する方法を提供します。Amendmentシステムは、ネットワークのコンセンサスの主要プロセスを利用して、継続的なサポートを含めて変更を承認し適用される仕組みになっています。Amendmentを適用するには通常、**80%のサポートが2週間にわたって**必要になります。
|
||||
|
||||
Amendmentが有効になると、そのAmendmentが含まれているバージョン以降のすべてのレジャーバージョンに永続的に適用されます。Amendmentを無効にすることはできません。ただし、Amendmentを無効にするための新しいAmendmentを導入する場合は除きます。
|
||||
|
||||
既知のAmendment、それらのステータス、およびIDのリストについては、以下を参照してください: [既知のAmendment](known-amendments.html)
|
||||
|
||||
## 背景
|
||||
|
||||
トランザクション処理に変更があると、サーバーで同じトランザクションのセットを使用して別のレジャーが作成される場合があります。一部の _バリデータ_ （[コンセンサスに参加している](rippled-server-modes.html#バリデータを運用する理由)`rippled`サーバー）が古いバージョンのソフトウェアを使用している状態で、他のバリデータが新しいバージョンのソフトウェアにアップグレードすると、ごく小さな問題から、場合によっては完全機能停止などの問題が生じる可能性があります。希なケースでは、少数のサーバーにおいて、実際のコンセンサスレジャーを取得するために、より多くの時間と帯域幅が使用される場合があります。既知のトランザクションの処理ルールを使ってレジャーを構築できないためです。最悪の場合、異なるルールを使用するサーバー間で当該レジャーについてコンセンサスに達することができないため、[コンセンサスプロセス][]により新しいレジャーバージョンを検証できない可能性があります。
|
||||
|
||||
Amendmentはこの問題を解決し、十分なバリデータがそれらの機能をサポートしている場合にのみ新しい機能を有効にします。
|
||||
|
||||
XRP Ledgerを使用しているユーザーや企業は、業務に影響を及ぼす可能性があるトランザクション処理の変更について事前に通知するためにAmendmentを使用することもできます。ただし、トランザクション処理や[コンセンサスプロセス][]に影響のないAPIを変更する場合、Amendmentは不要です。
|
||||
|
||||
[コンセンサスプロセス]: consensus.html
|
||||
|
||||
|
||||
## Amendmentについて
|
||||
|
||||
Amendmentは、正常に動作する機能や変更であり、コンセンサスプロセスの一環としてピアツーピアサーバーのネットワークで有効になるのを待っています。Amendmentを使用する`rippled`サーバーには、Amendmentなし（古い動作）とAmendmentあり（新しい動作）の2種類のモードのコードがあります。
|
||||
|
||||
各Amendmentには、識別用の一意の16進値および短縮名が付けられています。短縮名は人間が使用するためのものであり、Amendmentプロセスでは使用されません。説明用に異なった名前を使った場合でも、2つのサーバーで同じAmendment IDを使用できます。Amendmentの名前が一意であるという保証はありません。
|
||||
|
||||
慣例により、Rippleの開発者は、Amendment名のSHA-512HalfハッシュをAmendment IDとして使用します。
|
||||
|
||||
|
||||
## Amendmentプロセス
|
||||
|
||||
256番目毎のレジャーは、「フラグ」レジャーと呼ばれます。Amendmentの承認プロセスは、フラグレジャーの直前のレジャーバージョンで開始されます。`rippled`のバリデータサーバーは、そのレジャーの検証メッセージを送信するときに、具体的なAmendmentへの賛成票も送信します。バリデータがAmendmentに賛成票を投じない場合は、そのAmendmentに対して反対票を投じていることを意味します。（[手数料の投票](fee-voting.html)もフラグレジャーで行われます。）
|
||||
|
||||
フラグレジャー自体に特別な内容はありません。ただし、その間、サーバーは信頼するバリデータの投票を確認し、[`EnableAmendment` 疑似トランザクション](enableamendment.html)を次のレジャーに挿入するかどうかを決定します。EnableAmendmentの疑似トランザクションのフラグは、サーバーが発生したとみなす内容を示しています。
|
||||
|
||||
* `tfGotMajority`フラグは、Amendmentのサポートが、信頼できるバリデータの80%以上に増加したことを意味します。
|
||||
* `tfLostMajority`フラグは、Amendmentのサポートが、信頼できるバリデータの80%未満に減少したことを意味します。
|
||||
* フラグのないEnableAmendment擬似トランザクションは、そのAmendmentのサポートが有効になっていることを意味します。（トランザクション処理の変更は、これ以降のすべてのレジャーに適用されます。）
|
||||
|
||||
次の条件がすべて満たされた場合にのみ、サーバーは疑似トランザクションを挿入してAmendmentを有効にします。
|
||||
|
||||
* このAmendmentはまだ有効になっていない。
|
||||
* 前のレジャーには、`tfGotMajority`フラグが有効な状態で、このAmendmentに対するEnableAmendment疑似トランザクションが含まれている。
|
||||
* 当該前レジャーは、現行のレジャーの前のバージョンである。
|
||||
* 当該前レジャーの終了時刻は、最新のフラグレジャーの終了時刻の少なくとも**2週間**前である。
|
||||
* `tfGotMajority`疑似トランザクションと現行のレジャーの間のコンセンサスレジャーには、この修正に対するEnableAmendment疑似トランザクションで、`tfLostMajority`フラグが有効になっているものはない。
|
||||
|
||||
理論的には、`tfLostMajority` EnableAmendment擬似トランザクションを、Amendmentを有効にするための擬似トランザクションと同じレジャーに含めることができます。この場合、`tfLostMajority`擬似トランザクションを含む擬似トランザクションは効果がありません。
|
||||
|
||||
## Amendment投票
|
||||
|
||||
`rippled`の各バージョンは、既知のAmendmentのリストとそれらのAmendmentを実装するためのコードでコンパイルされています。デフォルトでは、`rippled`は既知のAmendmentをサポートし、未知のAmendmentに反対します。`rippled`バリデータのオペレーターは、特定のAmendmentが`rippled`バージョンにとって既知でない場合でも、そのAmendmentを明示的にサポートまたは反対するように[サーバーを設定](#amendment投票の設定)することができます。
|
||||
|
||||
有効にするには、Amendmentが、信頼済みのバリデータの80%以上に2週間継続してサポートされている必要があります。Amendmentのサポートが信頼できるバリデータの80%を下回ると、そのAmendmentは一時的に拒否されます。Amendmentが信頼済みのバリデータの少なくとも80%のサポートを取り戻した場合は、そこから2週間の期間が再スタートします。（この状況は、バリデータの投票内容が変わった場合や、バリデータの信頼に変化があった場合に発生します。）Amendmentが永続的に有効になるまでに、何度も過半数の支持を得たり失ったりすることがあります。Amendmentが永続的に拒否されることはありませんが、新しいバージョンの`rippled`の既知のAmendmentのリストにないAmendmentが有効になることはほとんどありません。
|
||||
|
||||
コンセンサスプロセスのすべてにおいてと同様に、Amendmentの投票は、投票を送信しているバリデータを信頼するサーバーによってのみ有効とみなされます。現時点では、Ripple社は、Rippleが運用するデフォルトのバリデータのみを信頼することを推奨しています。今のところ、新機能のリリースに関してRippleと協力するには、それらのバリデータのみを信頼するだけで十分です。
|
||||
|
||||
### Amendment投票の設定
|
||||
|
||||
[featureメソッド][]を使用してAmendmentを一時的に設定できます。サーバーのAmendmentに対するサポートを永続的に変更するには、サーバーの`rippled.cfg`ファイルを変更します。
|
||||
|
||||
サーバーに賛成票を投じさせたくないAmendmentを表示するには、`[veto_amendments]`スタンザを使用します。各行には1つのAmendmentの一意のIDを含める必要があり、必要に応じて、その後にAmendmentの短縮名を続けます。例:
|
||||
|
||||
```
|
||||
[veto_amendments]
|
||||
C1B8D934087225F509BEB5A8EC24447854713EE447D277F69545ABFA0E0FD490 Tickets
|
||||
DA1BD556B42D85EA9C84066D028D355B52416734D3283F85E216EA5DA6DB7E13 SusPay
|
||||
```
|
||||
|
||||
投票するAmendmentを表示するには、`[amendments]`スタンザを使用します。（ここで表示しなくても、サーバーは、適用方法を把握しているすべてのAmendmentにデフォルトで賛成票を投じます。）各行には1つのAmendmentの一意のIDを含める必要があり、必要に応じて、その後にAmendmentの短縮名を続けます。例:
|
||||
|
||||
```
|
||||
[amendments]
|
||||
4C97EBA926031A7CF7D7B36FDE3ED66DDA5421192D63DE53FFB46E43B9DC8373 MultiSign
|
||||
42426C4D4F1009EE67080A9B7965B44656D7714D104A72F9B4369F97ABF044EE FeeEscalation
|
||||
```
|
||||
|
||||
|
||||
### Amendment blocked
|
||||
|
||||
投票プロセス後にネットワークに対してAmendmentが有効になると、そのAmendmentを認識していない、以前のバージョンの`rippled`を実行しているサーバーは、ネットワークのルールを認識できなくなるため、「Amendment blocked」状態になります。Amendment blockedの状態のサーバーは次のようになります。
|
||||
|
||||
* レジャーのバリデータを判断できない
|
||||
* トランザクションを送信または処理できない
|
||||
* コンセンサスプロセスを行わない
|
||||
* 今後のAmendmentに投票しない
|
||||
|
||||
Amendment blockedは、XRP Ledgerに依存するアプリケーションを保護するためのセキュリティー機能です。新しいルールが適用された後のレジャーを推測したり誤解したりしないように、`rippled`は、Amendmentがどのように動作するか確認できないためにレジャーの状態が不明であると報告します。
|
||||
|
||||
`rippled`サーバーが賛成票または反対票を投じるように設定されているAmendmentは、そのサーバーがAmendment blockedの状態になるかどうかに影響を与えません。`rippled`サーバーは、可能な限り、ネットワークの他の部分によって有効なった一連のAmendmentに従います。有効なAmendmentがサーバーのソースコード内のAmendment定義に含まれていない場合、つまりAmendmentがサーバーよりも新しい場合にのみ、サーバーはAmendment blockedになります。
|
||||
|
||||
サーバーがAmendment blockedである場合は、[新しいバージョンにアップグレード](install-rippled.html)してネットワークと同期する必要があります。
|
||||
|
||||
|
||||
#### `rippled`サーバーがAmendment blockedの状態かどうかを確認する方法
|
||||
|
||||
`rippled`サーバーがAmendment blockedの状態であるという最初の兆候のひとつに、[トランザクションの送信時](submit.html)に返される`amendmentBlocked`エラーがあります。`amendmentBlocked`エラーの例を以下に示します。
|
||||
|
||||
```
|
||||
{
|
||||
"result":{
|
||||
"error":"amendmentBlocked",
|
||||
"error_code":14,
|
||||
"error_message":"Amendment blocked, need upgrade.",
|
||||
"request":{
|
||||
"command":"submit",
|
||||
"tx_blob":"479H0KQ4LUUXIHL48WCVN0C9VD7HWSX0MG1UPYNXK6PI9HLGBU2U10K3HPFJSROFEG5VD749WDPHWSHXXO72BOSY2G8TWUDOJNLRTR9LTT8PSOB9NNZ485EY2RD9D80FLDFRBVMP1RKMELILD7I922D6TBCAZK30CSV6KDEDUMYABE0XB9EH8C4LE98LMU91I9ZV2APETJD4AYFEN0VNMIT1XQ122Y2OOXO45GJ737HHM5XX88RY7CXHVWJ5JJ7NYW6T1EEBW9UE0NLB2497YBP9V1XVAEK8JJYVRVW0L03ZDXFY8BBHP6UBU7ZNR0JU9GJQPNHG0DK86S4LLYDN0BTCF4KWV2J4DEB6DAX4BDLNPT87MM75G70DFE9W0R6HRNWCH0X075WHAXPSH7S3CSNXPPA6PDO6UA1RCCZOVZ99H7968Q37HACMD8EZ8SU81V4KNRXM46N520S4FVZNSJHA"
|
||||
},
|
||||
"status":"error"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
次の`rippled`ログメッセージも、サーバーがAmendment blockedであることを示しています。
|
||||
|
||||
```
|
||||
2018-Feb-12 19:38:30 LedgerMaster:ERR One or more unsupported amendments activated: server blocked.
|
||||
```
|
||||
|
||||
`rippled`バージョン0.80.0以降を使用している場合は、[`server_info`](server_info.html)コマンドを使用して`rippled`サーバーがAmendment blockedであるかを確認できます。応答内で、`result.info.amendment_blocked`を探します。`amendment_blocked`が`true`に設定されている場合、サーバーはAmendment blockedの状態です。
|
||||
|
||||
**JSON-RPC応答の例:**
|
||||
|
||||
```
|
||||
{
|
||||
"result": {
|
||||
"info": {
|
||||
"amendment_blocked": true,
|
||||
"build_version": "0.80.1",
|
||||
"complete_ledgers": "6658438-6658596",
|
||||
"hostid": "ip-10-30-96-212.us-west-2.compute.internal",
|
||||
"io_latency_ms": 1,
|
||||
"last_close": {
|
||||
"converge_time_s": 2,
|
||||
"proposers": 10
|
||||
},
|
||||
...
|
||||
},
|
||||
"status": "success"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
サーバーがAmendment blockedでない場合、応答で`amendment_blocked`フィールドは返されません。
|
||||
|
||||
**注意:** `rippled` 0.80.0より前のバージョンでは、サーバーがAmendment blockedである場合でも`amendment_blocked`フィールドは含まれません。
|
||||
|
||||
|
||||
#### Amendment blockedの状態の`rippled`サーバーのブロックを解除する方法
|
||||
|
||||
サーバーがAmendment blockedとなる原因となっているAmendmentをサポートする`rippled`バージョンにアップグレードします。Rippleでは、[最新の`rippled`バージョンにアップグレード](install-rippled.html)してサーバーのブロックを解除し、ネットワークと再同期できるようにすることを推奨しています。
|
||||
|
||||
状況によっては、最新のバージョンよりも古い`rippled`バージョンにアップグレードすることで、サーバーのブロックを解除できる場合があります。これが可能なのは、その古いバージョンが、`rippled`サーバーをブロックしているAmendmentをサポートしている場合です。
|
||||
|
||||
**警告:** 最新の`rippled`バージョンでセキュリティーまたはその他の緊急の修正が提供されている場合は、できるだけ早く最新バージョンにアップグレードしてください。
|
||||
|
||||
最新バージョンよりも古いバージョンにアップグレードして`rippled`サーバーのブロックを解除できるかどうかを判断するには、サーバーをブロックしている機能を調べ、そのブロックしている機能をサポートしている`rippled`バージョンを調べます。
|
||||
|
||||
`rippled`サーバーをブロックしている機能を調べるには、[`feature`](feature.html)管理コマンドを使用します。`"enabled" : true`と`"supported" : false`を含む機能を探します。これらの機能の値は、最新のレジャーでAmendmentが現在有効になっている（必須）が、Amendmentをサポートまたは適用する方法がサーバーに認識されていないことを意味します。
|
||||
|
||||
**JSON-RPC応答の例:**
|
||||
|
||||
```
|
||||
{
|
||||
"result": {
|
||||
"features": {
|
||||
"07D43DCE529B15A10827E5E04943B496762F9A88E3268269D69C44BE49E21104": {
|
||||
"enabled": true,
|
||||
"name": "Escrow",
|
||||
"supported": true,
|
||||
"vetoed": false
|
||||
},
|
||||
"08DE7D96082187F6E6578530258C77FAABABE4C20474BDB82F04B021F1A68647": {
|
||||
"enabled": true,
|
||||
"name": "PayChan",
|
||||
"supported": true,
|
||||
"vetoed": false
|
||||
},
|
||||
"1562511F573A19AE9BD103B5D6B9E01B3B46805AEC5D3C4805C902B514399146": {
|
||||
"enabled": false,
|
||||
"name": "CryptoConditions",
|
||||
"supported": true,
|
||||
"vetoed": false
|
||||
},
|
||||
"157D2D480E006395B76F948E3E07A45A05FE10230D88A7993C71F97AE4B1F2D1": {
|
||||
"enabled": true,
|
||||
"supported": false,
|
||||
"vetoed": false
|
||||
},
|
||||
...
|
||||
"67A34F2CF55BFC0F93AACD5B281413176FEE195269FA6D95219A2DF738671172": {
|
||||
"enabled": true,
|
||||
"supported": false,
|
||||
"vetoed": false
|
||||
},
|
||||
...
|
||||
"F64E1EABBE79D55B3BB82020516CEC2C582A98A6BFE20FBE9BB6A0D233418064": {
|
||||
"enabled": true,
|
||||
"supported": false,
|
||||
"vetoed": false
|
||||
}
|
||||
},
|
||||
"status": "success"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
この例では、次の機能との競合により、`rippled`サーバーがAmendment blockedになっています。
|
||||
|
||||
* `157D2D480E006395B76F948E3E07A45A05FE10230D88A7993C71F97AE4B1F2D1`
|
||||
|
||||
* `67A34F2CF55BFC0F93AACD5B281413176FEE195269FA6D95219A2DF738671172`
|
||||
|
||||
* `F64E1EABBE79D55B3BB82020516CEC2C582A98A6BFE20FBE9BB6A0D233418064`
|
||||
|
||||
これらの機能をサポートしている`rippled`バージョンを見つけるには、[既知のAmendment](known-amendments.html)を参照してください。
|
||||
|
||||
|
||||
## Amendmentのテスト
|
||||
|
||||
Amendmentが有効になっている場合の`rippled`の動作を確認するには、そのAmendmentが実稼働ネットワークで有効になる前に、`rippled`の構成ファイルを実行して強制的に機能を有効にします。これは、開発目的でのみサポートされています。
|
||||
|
||||
コンセンサスネットワークの他のメンバーはこの機能を有効にしていない可能性があるため、実稼働ネットワークに接続されている間はこの機能を使用しないでください。機能を強制的に有効にしてテストしている間は、[スタンドアロンモード](rippled-server-modes.html#rippledサーバーをスタンドアロンモードで実行する理由)で`rippled`を実行する必要があります。
|
||||
|
||||
機能を強制的に有効にするには、`[features]`スタンザを`rippled.cfg`ファイルに追加します。このスタンザで、有効にする機能の名前の短縮名を1行に1つずつ追加します。例:
|
||||
|
||||
```
|
||||
[features]
|
||||
MultiSign
|
||||
TrustSetAuth
|
||||
```
|
||||
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -1,6 +1,6 @@
|
||||
# Amendments
|
||||
|
||||
[Introduced in: rippled 0.31.0][New in: rippled 0.31.0]
|
||||
[Introduced in: rippled 0.31.0][]
|
||||
|
||||
The Amendments system provides a means of introducing new features to the decentralized XRP Ledger network without causing disruptions. The amendments system works by utilizing the core consensus process of the network to approve any changes by showing continuous support before those changes go into effect. An amendment normally requires **80% support for two weeks** before it can apply.
|
||||
|
||||
|
||||
@@ -313,7 +313,7 @@ Changes the result codes returned by two transaction types:
|
||||
|
||||
Adds delivered amount to metadata for CheckCash transactions cashed for a flexible amount. (Has no effect unless the [Checks](#checks) amendment is enabled.)
|
||||
|
||||
With this amendment enabled, transaction processing adds a `DeliveredAmount` field to the metadata of [CheckCash transactions][] for a variable amount (using the `DeliverMin` field). This change is written to the ledger data, resulting in a different ledger hash than would result from processing the transaction without this amendment. It does not affect the actual amounts delivered. Additionally, with this amendment enabled, the [tx method][] and [account_tx method][] return a [`delivered_amount` field](transaction-metadata.html#delivered-amount) for CheckCash transactions. (The `delivered_amount` field is calculated when you look up a transaction, and is not part of the data that is written to the ledger.)
|
||||
With this amendment enabled, transaction processing adds a `DeliveredAmount` field to the metadata of [CheckCash transactions][] for a variable amount (using the `DeliverMin` field). This change is written to the ledger data, resulting in a different ledger hash than would result from processing the transaction without this amendment. It does not affect the actual amounts delivered. Additionally, with this amendment enabled, the [tx method][] and [account_tx method][] return a [`delivered_amount` field](transaction-metadata.html#delivered_amount) for CheckCash transactions. (The `delivered_amount` field is calculated when you look up a transaction, and is not part of the data that is written to the ledger.)
|
||||
|
||||
The fix1623 amendment has no effect on [CheckCash transactions][] for a fixed amount (using the `Amount` field) or any other transaction types.
|
||||
|
||||
|
||||
@@ -0,0 +1,104 @@
|
||||
# コンセンサスの原理とルール
|
||||
|
||||
XRP Ledgerは世界規模の決済システムで、ユーザーはメールを送るときのようにスムーズに国境を越えて送金することができます。Bitcoinなどの他のピアツーピア決済ネットワークと同様に、XRP Ledgerでは分散型コンピューターネットワークを介したピアツーピア取引の決済が可能です。他のデジタル通貨プロトコルとは異なり、XRP LedgerではXRP（XRP Ledgerのネイティブ資産）の他にユーザーが選択した通貨（法定通貨、デジタル通貨、その他の価値形態など）建てでトランザクションを実行できます。
|
||||
|
||||
XRP Ledgerのテクノロジーにより、ほぼリアルタイムでの決済（3～6秒）が可能です。また、その分散型取引所により自動的に最も安価な通貨取引注文を決済に適用して通貨をブリッジングすることができます。
|
||||
|
||||
# 背景
|
||||
|
||||
## 仕組み
|
||||
|
||||
根本的には、XRP Ledgerはアカウント、残高、および資産取引オファーなどの情報を記録する共有データベースです。「トランザクション」と呼ばれる署名付きの指示により、アカウントの作成、支払いの実行、資産の取引などの変更が行われます。
|
||||
|
||||
暗号化システムであるため、XRP Ledgerアカウントの所有者は _暗号ID_ により識別されます。暗号IDは、公開鍵/秘密鍵のペアに相当します。トランザクションは、暗号IDに一致する暗号署名によって承認されます。すべてのサーバーでは、同一の確定的な既知のルールに基づいてすべてのトランザクションが処理されます。最終的な目標は、ネットワーク内のすべてのサーバーがまったく同じレジャー状態の完全なコピーを保有できるようにし、1つの中央機関がトランザクションを調停する必要がないようにすることです。
|
||||
|
||||
|
||||
## 二重支払いの問題
|
||||
|
||||
「二重支払い」の問題は、どのような決済システムの運用においても根本的な課題となります。この問題は、ある場所でお金を支払うときに、別の場所ではそのお金を支払うことができないという要件に起因しています。一般的には、2つのトランザクションがあり、いずれかのトランザクションが有効で、両方が同時に有効になることがない場合にこの問題が発生します。
|
||||
|
||||
たとえば、Alice、Bob、Charlieが決済システムを使用しており、Aliceの残高が$10であるとします。この決済システムが機能するためには、Aliceはこの$10をBobまたはCharlieに送金できる必要があります。ただしAliceがBobに$10を送金し、同時にCharlieにも$10を送金しようとすると、二重支払いの問題が発生します。
|
||||
|
||||
Aliceが「同じ」$10をCharlieとBobの両方に送金できてしまう場合、この決済システムは正しく機能したとはいえなくなります。決済システムでは、発生したトランザクションについてすべての参加者が合意できるように、成功すべきトランザクションと失敗すべきトランザクションを選択する手段が必要です。これら2つのトランザクションはいずれも、トランザクションとしては同じく有効です。ただし、どのトランザクションが最初に発生したかについては、決済システムの参加者によって見方が異なります。
|
||||
|
||||
従来、決済システムでは中央機関がトランザクションを追跡、承認することで、この二重支払いの問題が解決されてきました。たとえば銀行は唯一の管理人として、保有する小切手振出人の預金残高に基づいて小切手を決済します。このようなシステムでは、すべての参加者が中央機関の決定に従う必要があります。
|
||||
|
||||
XRP Ledgerなどの分散型台帳技術では中央機関が存在せず、二重支払いの問題を他の方法で解決する必要があります。
|
||||
|
||||
|
||||
# コンセンサスの仕組み
|
||||
|
||||
## 問題の単純化
|
||||
|
||||
二重支払いの問題のほとんどは、既知のルール（アカウントが保有していない資金を利用することを禁止するなど）により解決できます。実際に、二重支払いの問題はトランザクションを順に整理することで削減できます。
|
||||
|
||||
BobとCharlieの両方に同じ$10を送金しようとしたAliceの例で説明します。Bobへの支払いが最初であることが判明している場合は、AliceにはBobに支払う資金があることで全員が合意できます。Charlieへの支払いが2番目であることが判明している場合は、資金はすでにBobに送金されたため、Charlieには資金を送金できないことで全員が合意できます。
|
||||
|
||||
また、確定的なルールに基づいてトランザクションを順に並べることもできます。トランザクションはデジタル情報の集合であるため、コンピューターで簡単にソートできます。
|
||||
|
||||
中央機関なしに二重支払いの問題を解決するにはこれで十分ですが、トランザクションの結果を確認する前に、発生するすべてのトランザクションを把握し、ソートする必要があります。これは明らかに非現実的です。 <!-- STYLE_OVERRIDE: obviously -->
|
||||
|
||||
トランザクションをグループにまとめ、グループ単位で合意できる場合には、グループ内でトランザクションをソートできます。ひとまとめで処理するトランザクションについて参加者全員が合意している限り、中央機関を必要とすることなく、確定的なルールに基づいて二重支払いの問題を解決できます。各参加者がトランザクションをソートし、既知のルールに従い確定的な方法でそれらのトランザクションを適用します。XRP Ledgerでは、二重支払いの問題をこの方法で解決します。
|
||||
|
||||
XRP Ledgerでは、合意されたグループに複数の競合するトランザクションを含めることができます。トランザクションのグループは確定的なルールに従って実行されるので、ソートルールに基づいて最初に発生したトランザクションが成功し、2番目に発生した競合するトランザクションは失敗します。
|
||||
|
||||
## コンセンサスルール
|
||||
|
||||
コンセンサスの主な役割は、プロセスの参加者が、二重支払いの問題を解決するためグループ単位で処理するトランザクションについて合意を形成できるようにすることです。次の4つの理由により、この合意の形成は予想以上に容易です。
|
||||
|
||||
1. トランザクションをトランザクショングループに含めてはならない理由が特にない場合、すべての公正な参加者はそのトランザクションをグループに含めることで合意します。すべての参加者がすでに合意している場合、コンセンサスが果たす役割はありません。
|
||||
2. トランザクションをトランザクショングループに含めてはならない何らかの理由がある場合、すべての公正な参加者はそのトランザクションの除外を希望します。トランザクションがまだ有効であり、次のラウンドに含めてはならない理由が特にない場合は、そのトランザクションを次のラウンドに含めることで全員が合意します。
|
||||
3. トランザクションをグループ化する方法に参加者が特に関心を示すことは極めてまれです。合意の形成は、参加者全員がこれを最優先と認識している場合は最も容易になされ、参加者の関心が異なる場合に限り難しくなります。
|
||||
4. 確定的なルールはグループ編成時にも使用でき、エッジケースについてのみ不合意を形成します。たとえば、ラウンドに2つの競合するトランザクションがある場合、確定的なルールを使用して次のラウンドに含めるトランザクションを決定できます。
|
||||
|
||||
すべての参加者は正確さを最も重視します。共有レジャーの整合性を損なわないようにするため、最初にこれらのルールを適用する必要があります。たとえば、適切な署名がないトランザクションは（他の参加者が処理を希望する場合でも）処理されることはありません。ただし、公正な参加者全員が2番目に重視するのは合意です。二重支払いが発生する可能性のあるネットワークはまったく役に立ちません。公正な参加者全員が正確さの次に重視するのが合意であるという事実により、合意が促進されます。
|
||||
|
||||
## コンセンサスラウンド
|
||||
|
||||
コンセンサスラウンドとは、トランザクションのグループについての合意形成に向けた取り組みで、これによりトランザクションの処理を可能とします。コンセンサスラウンドでは、合意形成を希望する各参加者が最初の見解を表明します。これは、参加者が確認した有効なトランザクションセットです。
|
||||
|
||||
次に、合意に向けて、参加者の見解が「次々に寄せられます」。特定のトランザクションが過半数の支持を得られない場合、参加者はそのトランザクションの保留に合意します。特定のトランザクションが過半数の支持を得ている場合、参加者はそのトランザクションを追加することに合意します。このように、支持が過半数をわずかに上回れば即座に全面的に支持され、過半数をわずかに下回れば即座に現行ラウンドでは全面的に却下されることになります。
|
||||
|
||||
コンセンサスが50%前後で行き詰まることを防ぎ、確実な合意を形成する上で必要となる重複を低減するため、トランザクションの追加に関する所定のしきい値は時間の経過とともに増加します。最初は、50%以上の他の参加者が合意していれば、参加者はトランザクションの追加についての合意の継続を支持します。参加者が合意しない場合、このしきい値が増加します。最初は60%に増加し、その後は問題のトランザクションが現行セットから削除されるまで増加し続けます。このようにして除外されたトランザクションはすべて次のレジャーバージョンに繰り越されます。
|
||||
|
||||
次に処理するトランザクションセットについて圧倒的多数が合意し、参加者がこれを確認した場合は、コンセンサスに達したと宣言します。
|
||||
|
||||
## コンセンサス失敗の可能性
|
||||
|
||||
完全なコンセンサスの達成に失敗することがないコンセンサスアルゴリズムの開発は非現実的です。その理由を理解するため、コンセンサスプロセスがどのように終了するかについて説明します。各参加者はある時点で、コンセンサスに達し、特定のトランザクションセットがそのコンセンサスプロセスの結果であると宣言する必要があります。この宣言により参加者は、特定のトランザクションセットがコンセンサスプロセスの結果であると取り消し不能の表明をすることになります。
|
||||
|
||||
いずれかの参加者がこの宣言を最初に行う必要があります。この宣言を行なう参加者がいなければ、合意に達することができません。次に、この宣言を最初に行う参加者について説明します。最初に宣言を行う参加者が、コンセンサスは完了したと判断した時点では、他の参加者はまだそのような判断に至っていません。もし他の参加者が各自の視点をもとに合意済のセットを変更できないのであれば、最初の宣言が行われた時点で、他の参加者はコンセンサスは完了したと判断していたでしょう。したがって、参加者は合意済のセットを変更できるはずです。 <!-- STYLE_OVERRIDE: will -->
|
||||
|
||||
つまり、コンセンサスプロセスを完了するには、その他のすべての参加者が合意済のトランザクションセットを理論的に変更できる場合でも、特定の参加者がトランザクションセットについてコンセンサスに達したことを宣言する必要があります。
|
||||
|
||||
たとえば、あるグループが部屋の中でどのドアから外に出るかについて合意しようとしている場合を考えてください。参加者がどれほど話し合っても、ある時点で _誰か_ が最初にドアから外に出なければなりません。これは、その後に続く人々が考えを変えて別のドアから外に出ることができるとしてもです。
|
||||
|
||||
このような失敗が生じる確率を低く抑えることはできますが、ゼロにすることはできません。技術上のトレードオフとして、この確率を1000分の1未満に抑えると、コンセンサスにかかる時間が非常に長くなり、ネットワークとエンドポイントの障害に対する耐性が低くなります。
|
||||
|
||||
## XRP Ledgerでのコンセンサス失敗の処理
|
||||
|
||||
コンセンサスラウンドが完了したら、各参加者は、合意に達したと各自が理解しているトランザクションのセットを適用します。その結果、レジャーの次の段階と各自が想定しているものが生成されます。
|
||||
|
||||
バリデータでもある参加者が、次のレジャーの暗号フィンガープリントを公開します。このフィンガープリントを「検証投票」と呼びます。コンセンサスラウンドが成功した場合、公正なバリデータの過半数が同じフィンガープリントを公開します。
|
||||
|
||||
次に参加者がこれらの検証投票を収集します。検証投票から、参加者は前のコンセンサスラウンドの結果、参加者の圧倒的多数がトランザクションセットについて合意しているか否かを確認できます。
|
||||
|
||||
参加者は次の3つのいずれかの状況になります（確率の高い順）。
|
||||
|
||||
1. 圧倒的多数が合意したレジャーと同じレジャーを構築します。この場合、参加者はそのレジャーが完全に検証済みであると見なし、その内容を信頼できます。
|
||||
2. 圧倒的多数が合意したレジャーとは異なるレジャーを構築します。この場合、参加者は圧倒的多数が合意したレジャーを構築して受け入れる必要があります。これは通常、参加者が早期にコンセンサスを宣言した後、他の多くの参加者が考えを変えたことを意味します。圧倒的多数が合意したレジャーに「ジャンプ」して操作を再開する必要があります。
|
||||
3. 受信した検証からは圧倒的多数が明確ではありません。この場合、前のコンセンサスラウンドが無駄となったため、いずれかのレジャーが検証される前に新しいラウンドが発生する必要があります。
|
||||
|
||||
ケース1が最も一般的に発生する状況です。ケース2はネットワークに一切悪影響を及ぼしません。ごく少数の参加者は、あらゆるラウンドでケース2の状況になることがありますが、ネットワークは特に問題なく動作します。このような参加者も、構築したレジャーが圧倒的多数が支持するレジャーと同じでなかったことを認識できるので、圧倒的多数との合意に達するまでは、その結果を最終結果として報告してはならないことを理解しています。
|
||||
|
||||
ケース3では、ネットワークは数秒間遅滞する結果となります。この間に処理を進められる可能性はありますが、非常にまれです。このケースでは、意見の相違はコンセンサスプロセスで解決され、未解決のまま残っている意見の相違のみが失敗の原因となるため、次のコンセンサスラウンドが失敗する可能性は大幅に低下します。
|
||||
|
||||
まれに、ネットワーク全体が数秒間にわって処理を進めることができないことがあります。その代わり、トランザクションの平均確認時間は短くなります。
|
||||
|
||||
# 理念
|
||||
|
||||
信頼性の1つの要素として、一部のコンポーネントで障害が発生している、悪意のある参加者がいるなどの状況でも結果を提供できるというシステムの能力があげられます。この点は重要ですが、暗号決済システムに関してはこれよりもさらに重要なもう1つの信頼性の要素があります。それは、信頼できる結果を提供するシステムの能力です。つまり、システムが結果を信頼できるものとして報告する場合、その結果を信頼できなければなりません。
|
||||
|
||||
ただし実際のシステムは、この両方の信頼性が損なわれる可能性のある運用状況に直面します。このような状況には、ハードウェア障害、通信障害、不正な参加者などがあります。XRP Ledgerの設計理念の1つとして、信頼してはならない結果を提供するのではなく、結果の信頼性が損なわれている状況を検知し、報告することを掲げています。
|
||||
|
||||
XRP Ledgerのコンセンサスアルゴリズムは、プルーフオブワークシステムに代わる堅牢な仕組みで、コンピューティングリソースを不必要に消費することはありません。ビザンチン障害が発生する可能性があり、また実際に発生することがありますが、その影響はわずかな遅延にとどまります。どのケースでも、XRP Ledgerのコンセンサスアルゴリズムは、結果が実際に信頼できるものである場合にのみ、信頼できる結果として報告します。
|
||||
@@ -0,0 +1,67 @@
|
||||
# 攻撃および障害モードに対するコンセンサスの保護
|
||||
|
||||
XRP Ledgerコンセンサスプロトコルは、 _ビザンチンフォールトトレラント性_ のあるコンセンサスメカニズムです。つまり、あらゆる不適切な状況（参加者が信頼できないオープンネットワークを利用して通信している場合や、不正使用者が常にシステムを乗っ取ろうとしているかまたは中断しようとしている場合など）が発生しても動作するように設計されています。さらに、XRP Ledgerコンセンサスプロトコルの参加者が事前に判明していない場合や、時間の経過とともに変わる場合があります。
|
||||
|
||||
[ネットワークに求められる特性](intro-to-consensus.html#コンセンサスプロトコルの特性)を維持しつつ、トランザクションをタイミングよく承認する作業は複雑であり、また完璧なシステムを構築することは不可能です。XRP Ledgerコンセンサスプロトコルは、ほとんどの状況で機能し、機能できない状況では可能な限り安全に失敗するように設計されています。
|
||||
|
||||
このページでは、XRP Ledgerコンセンサスプロトコルのいくつかの課題のタイプとその対処について説明します。
|
||||
|
||||
## 個々のバリデータの不適切な動作
|
||||
|
||||
_バリデータ_ とは、新しいレジャーバージョンの決定プロセスにアクティブに参加するサーバーです。バリデータは、そのバリデータを信用するように設定されているサーバーにのみ影響を与えます（間接的な影響を含む）。一部バリデータの動作が不適切であってもコンセンサスを継続できます。このような不適切な動作には、以下のさまざまなケースがあります。
|
||||
|
||||
- 使用できないかまたは過負荷状態である。
|
||||
- ネットワークから部分的に切断されており、メッセージが遅延なしで届くのは一部の参加者に限られる。
|
||||
- 他のサーバーを欺くかまたはネットワークを停止する目的で意図的に動作している。
|
||||
- 外部要因（抑圧的な政府からの脅威など）からのプレッシャーによって不正に動作している。
|
||||
- バグまたは古いソフトウェアが原因で、わかりにくいメッセージまたは誤った形式のメッセージが偶発的に送信される。
|
||||
|
||||
一般に、信頼できるバリデータのうち、不適切に動作しているバリデータがごくわずか（約20%未満）である限り、特に問題なくコンセンサスを継続できます。（正確な割合とその計算については、最新の[コンセンサスに関する研究](consensus-research.html)を参照してください。）
|
||||
|
||||
バリデータの約20%以上がアクセス不能であるか適切に動作していない場合、ネットワークはコンセンサスに達することができません。この間、新しいトランザクションを暫定的に処理できますが、新しいレジャーバージョンを検証できないため、これらのトランザクションの最終結果は未確定になります。このような状況では、XRP Ledgerが正常ではないことがただちに明らかになるため、待機するか、または信頼できるバリデータのセットを再設定するかを決定できる参加者からの人的介入が促されます。
|
||||
|
||||
無効なトランザクションを承認する唯一の方法は、80%以上の信頼できるバリデータがそのトランザクションを承認し、その結果に合意することです。（無効なトランザクションには、すでに使用された資金を送金するトランザクションや、ネットワークのルールに違反するトランザクションなどがあります。）つまり、信頼できるバリデータの過半数が _共謀する_ 必要があります。多数の信頼できるバリデータが世界各地域で異なる人々や企業により運用されている状況では、意図的にこれを達成することは非常に困難です。
|
||||
|
||||
|
||||
## ソフトウェアの脆弱性
|
||||
|
||||
あらゆるソフトウェアシステムと同様に、XRP Ledgerコンセンサスプロトコル、広く導入されているソフトウェアパッケージ、またはその依存関係の実装に伴うバグ（または意図的に悪意のあるコード）の問題には、真剣に取り組む必要があります。巧妙に作成された入力を取り込んだサーバーをクラッシュさせるだけのバグであっても、ネットワークの進捗を妨害する目的で悪用される可能性があります。Rippleではこのような脅威に対処するため、次のようなさまざまな対策を導入しています。
|
||||
|
||||
- [オープンソースコードベース](https://github.com/ripple/rippled/)。これにより、一般のユーザーが関連ソフトウェアをレビュー、コンパイルし、個別にテストできます。
|
||||
- 公式XRP Ledgerリポジトリのあらゆる変更のための綿密で堅固なコードレビュープロセス。
|
||||
- すべてのリリースと公式ソフトウェアパッケージへのRipple社員によるデジタル署名付与。
|
||||
- セキュリティの脆弱性と不安定さに関する定期的に委託された専門家レビュー。
|
||||
- 責任を持って脆弱性を公開したセキュリティ研究者に報奨金を授与する[Bug Bountyプログラム](https://ripple.com/bug-bounty/)。
|
||||
|
||||
|
||||
## シビル攻撃
|
||||
|
||||
_[シビル攻撃](https://en.wikipedia.org/wiki/Sybil_attack)_ とは、大量の偽IDを使ってネットワークのコントロールを試みる攻撃です。XRP Ledgerでは、シビル攻撃は多数のバリデータを操作して、他のバリデータにこれらのバリデータを信頼するように仕向ける形で攻撃をしかける可能性があります。このような攻撃は理論上は可能ですが、バリデータが信頼を得るには人間による介入が必要であるため、実際には非常に困難です。
|
||||
|
||||
攻撃者が操作する検証サーバーの数に関係なく、既存の参加者が攻撃者のバリデータを信頼しない限りは、これらの参加者が何を検証済みと判断するかについて、このようなサーバーが影響を及ぼすことはできません。その他のサーバーは、バリデータリストまたは明示的な設定によって信頼できると設定されたバリデータのみを信頼します。（デフォルトのバリデータリストの仕組みの概要については、[バリデータ重複要件](#バリデータ重複要件)を参照してください。）
|
||||
|
||||
この信頼は自動的に形成されるものではありません。したがってシビル攻撃を成功させるには、ターゲットとなる人物や企業が、攻撃者のバリデータを信頼してXRP Ledgerサーバーを再設定するように仕向けるという難しい作業をこなさなければなりません。ある人物または企業がだまされてXRP Ledgerサーバーを再設定したとしても、自らの設定を変更していない他の人物や企業に対する影響は最小限となります。
|
||||
|
||||
|
||||
## 51%攻撃
|
||||
|
||||
「51%攻撃」とは、特定の当事者が全採掘能力または投票能力の50%を超える割合を支配しているブロックチェーンに対する攻撃です。（厳密には、50%を _わずかでも_ 超えていれば十分であるため、この攻撃の名前は多少間違っています。）XRP Ledgerは、コンセンサスメカニズムに採掘を採用していないため、51%攻撃に対し脆弱ではありません。これに最も類似するXRP Ledgerへの攻撃には[シビル攻撃](#シビル攻撃)がありますが、この攻撃を実際に実施することは困難です。
|
||||
|
||||
|
||||
## バリデータ重複要件
|
||||
|
||||
XRP Ledgerのすべての参加者が何を検証済みとみなすかについて合意するには、参加者はまず、他の参加者が選択したバリデータ群によく似た信頼できるバリデータ群を選択する必要があります。最悪のケースでは、重複が約90%未満のために一部の参加者間に不一致が生じる場合があります。このため、Rippleは推奨バリデータの署名付きリストを公開しています。このリストには、企業や業界、コミュニティが運用する信頼性が高く適切に管理されたサーバーが含まれます。
|
||||
|
||||
デフォルトでは、XRP LedgerサーバーはRippleが運用するバリデータリストサイトを使用するように設定されています。このサイトでは、Rippleが定期的に更新する推奨バリデータリスト（推奨 _ユニークノードリスト_ （UNL））が公開されています。このように設定されているサーバーは、最新バージョンのリストに含まれているすべてのバリデータを信頼します。これにより、同じリストを使用する他のサーバーと100%重複することが保証されます。デフォルトの設定には、サイトのコンテンツの真正性を検証する公開鍵が含まれています。サイトがダウンした場合、XRP Ledgerのピアツーピアネットワーク内のサーバー間でリストに対する署名済みの更新を直接中継できます。
|
||||
|
||||
技術的には、サーバーを実行している場合、各自のリストサイトを設定するかまたは信頼できるバリデータを個別に明示的に選択することができますが、これらを行うことは推奨されません。選択したバリデータ群と他のサーバーとの重複が十分ではない場合、サーバーはネットワークの他の部分と不一致になる可能性があり、サーバーが不一致の状態でアクションを実行すると資金を失う可能性があります。
|
||||
|
||||
コンセンサスプロトコルの設計を改善し、より多様性のあるバリデータリストを実現するための研究が進んでいます。詳細は、[コンセンサスの研究](consensus-research.html)ページを参照してください。
|
||||
|
||||
|
||||
## 関連項目
|
||||
|
||||
- コンセンサスの**入門レベルの概要**については、[コンセンサスについて](intro-to-consensus.html)を参照してください。
|
||||
- コンセンサスプロトコルの**詳細な説明**については、[コンセンサス](consensus.html)を参照してください。
|
||||
- コンセンサスプロトコルの**設計に関する決定と背景**については、[コンセンサスの原理とルール](consensus-principles-and-rules.html)を参照してください。
|
||||
- コンセンサスプロトコルの特性と制約に関する**学術研究**については、[コンセンサスの研究](consensus-research.html)を参照してください。
|
||||
@@ -0,0 +1,9 @@
|
||||
# コンセンサスの研究
|
||||
|
||||
Rippleでは、XRP Ledgerのコンセンサスプロトコルの理論上の制限と実際の制限の両方についての研究を進め、この分野にてさまざまなアイデアを探究しています。以下の表に、Rippleが発表した学術論文の一覧を示します。
|
||||
|
||||
| 日付 | タイトル | 著者 | 概要 |
|
||||
|---|---|---|---|
|
||||
| 2018-02-20 | [Cobalt: BFT Governance in Open Networks](https://arxiv.org/abs/1802.07240) | MacBrough | コンセンサスUNLの柔軟性を高める新しいアトミックブロードキャストアルゴリズム、Cobaltの紹介。 |
|
||||
| 2018-02-20 | [Analysis of the XRP Ledger Consensus Protocol](https://arxiv.org/abs/1802.07242) | Chase, MacBrough | XRP Ledgerのコンセンサスアルゴリズムとその安全性および活性の特性に関する最新の詳細な分析。 |
|
||||
| 2014 | [The Ripple Protocol Consensus Algorithm](https://ripple.com/files/ripple_consensus_whitepaper.pdf) | Schwartz, Youngs, Britto | XRP Ledgerで採用されているコンセンサスアルゴリズムの紹介。 |
|
||||
193
content/concepts/consensus-network/consensus.ja.md
Normal file
193
content/concepts/consensus-network/consensus.ja.md
Normal file
@@ -0,0 +1,193 @@
|
||||
# コンセンサス
|
||||
|
||||
_著者: Dave Cohen、David Schwartz、Arthur Britto_
|
||||
|
||||
この記事では、XRP Ledgerの概要や格納される情報、[トランザクション](transaction-formats.html)によってレジャー（台帳）が変化する様子について説明します。
|
||||
|
||||
XRP Ledger上でアプリケーションを構築する場合は、XRP Ledger APIの動作や、その動作によってもたされる影響を知っておくために、このプロセスを理解することが重要です。
|
||||
|
||||
|
||||
## まえがき
|
||||
|
||||
ピアツーピアサーバーのXRP Ledgerネットワークは世界で共有されている台帳であり、ここから、アプリケーションはこの台帳の内容の状態に関して信頼できる情報を得ることができます。この状態に関する情報には以下の内容が含まれます。
|
||||
|
||||
- 各[アカウント](accounts.html)の設定
|
||||
- XRPおよび[発行済み通貨](issued-currencies.html)の残高
|
||||
- 分散型取引所でのオファー（注文）
|
||||
- ネットワーク設定（例: [トランザクションコスト](transaction-cost.html)と[準備金](reserves.html)の金額）
|
||||
- タイムスタンプ
|
||||
|
||||
レジャーバージョンに含まれるデータの詳細な技術説明については、[レジャーフォーマットのリファレンス](ledger-data-formats.html)を参照してください。
|
||||
|
||||
[](img/anatomy-of-a-ledger-complete.ja.png)
|
||||
|
||||
_図1: XRP Ledgerの要素_
|
||||
|
||||
XRP Ledgerでは、数秒ごとに新しいレジャーバージョンが作成されます。あるレジャーバージョンの内容にネットワークが同意すると、そのレジャーバージョンは _検証済み_ となり、その内容が変更されることはありません。それ以前の検証済みのレジャーバージョンによって、レジャー履歴が形成されます。検証済みの最新のレジャーも、少し前の時点のネットワークの状態を表しており、履歴の一部となります。現時点で、ネットワークは次のレジャーバージョンに適用されてファイナライズされる可能性のあるトランザクションを評価しています。この評価が行われている間、ネットワークには、検証前のレジャーバージョン候補が存在します。
|
||||
|
||||
[](img/ledger-history.ja.png)
|
||||
|
||||
_図2: XRP Ledgerのシーケンスと履歴_
|
||||
|
||||
レジャーバージョンには2つの識別子があります。1つは _レジャーインデックス_ で、 _シーケンス番号_ とも呼ばれます。レジャーバージョンの番号は1つずつ増加します。例えば、現行のレジャーバージョンのレジャーインデックスが100の場合、1つ前はレジャーインデックス99、1つ後はレジャーインデックスは101です。もう1つの識別子は _レジャーハッシュ_ で、レジャーの内容のデジタル指紋を表します。
|
||||
|
||||
サーバーがレジャーに適用するトランザクションを提案するときに、内容がわずかに異なる複数の候補レジャーバージョンが作成される場合があります。このような候補レジャーバージョンでは、レジャーインデックスは同じですがレジャーハッシュが異なります。多くの候補のうち、検証済みとなるのは1つだけです。それ以外の候補レジャーバージョンはすべて、破棄されます。そのため、履歴内の各レジャーインデックスに対して存在する検証済みのレジャーハッシュは1つのみです。
|
||||
|
||||
レジャーに対するユーザーレベルの変更は、トランザクションによってなされます。[トランザクション](transaction-formats.html)の例としては、決済、アカウントの設定またはトラストラインの変更、取引のオファー（注文）などがあります。各トランザクションは、レジャーに対する1つ以上の変更を承認するものであり、アカウント所有者によって暗号署名されます。アカウントの変更を承認したり、レジャーのそれ以外の内容を変更したりするには、トランザクションによるしかありません。
|
||||
|
||||
各レジャーバージョンには、一連のトランザクションと、そのようなトランザクションに関するメタデータも含まれています。それらのトランザクションは、新しいレジャーバージョンを作成するために前のバージョンのレジャーに適用されたものです。メタデータには、レジャーの状態データに対する、トランザクションの影響が正確に記録されています。
|
||||
|
||||
[](img/ledger-changes.ja.png)
|
||||
|
||||
_図3: レジャーバージョンに適用されるトランザクション_
|
||||
|
||||
レジャーインスタンスに含まれる一連のトランザクションはそのレジャーに記録され、XRP Ledger履歴の監査を可能としています。レジャーN+1のアカウント残高がレジャーNのアカウント残高と異なる場合、レジャーN+1にはその変更の原因となったトランザクションが含まれます。
|
||||
|
||||
検証済みのレジャー内に出現するトランザクションは、レジャーの変更に成功したか、または要求されたアクションを実行せずに処理された可能性があります。成功したトランザクションには、要求された変更がレジャーに適用されたことを示す**tesSUCCESS** [結果コード](transaction-results.html)が含まれます。レジャー内の失敗したトランザクションには、**tec**クラスの結果コードが含まれます。<a href="#footnote_1" id="from_footnote_1"><sup>1</sup></a>
|
||||
|
||||
レジャーに含まれるトランザクションでは必ず、[トランザクションコスト](transaction-cost.html)として一部のXRPが消却されます。この場合、**tes**コードまたは**tec**コードが含まれていたかどうかは関係ありません。消却するXRPの正確な量は、署名されたトランザクションの手順で定義されます。
|
||||
|
||||
**tes**クラスや**tec**クラスの結果コード以外に、**ter**クラス、**tef**クラス、および**tem**クラスのコードがあります。後者の3つは、APIの呼び出しによって返された暫定的な失敗を示します。レジャーには、**tes**および**tec**のコードのみ表示されます。レジャーに含まれていないトランザクションによって、レジャーの状態（XRP残高を含む）が影響を受けることはありませんが、暫定的に失敗したトランザクションが後で成功する可能性があります。
|
||||
|
||||
[`rippled` API](rippled-api.html)を使用する場合、レジャーに含めるように提案された候補トランザクションと、検証済みのレジャーに含まれる検証済みのトランザクションをアプリケーションで区別する必要があります。検証済みのレジャー内にあるトランザクションの結果のみが不変です。検証済みのレジャーには、候補トランザクションが含まれる場合と含まれない場合があります。
|
||||
|
||||
重要: 一部の[`rippled` API](rippled-api.html)では、候補トランザクションに基づき暫定的な結果が返されます<a href="#footnote_2" id="from_footnote_2"><sup>2</sup></a>。アプリケーションで、トランザクションの最終的な結果を判断する目的で暫定的な結果を使用するのは望ましくありません。最終的にトランザクションが成功したことを確実に知る唯一の方法は、そのトランザクションが検証済みのレジャー内にあり、かつ、結果コードがtesSUCCESSになるまで、トランザクションの状況を確認することです。トランザクションが検証済みレジャー内にあるが、結果コードがそれ以外の場合、トランザクションの失敗を意味します。トランザクションの[`LastLedgerSequence`](transaction-common-fields.html)で指定されたレジャーが検証済みにもかかわらず、そのトランザクションがそのレジャーまたはそれ以前の他のレジャー内にない場合、トランザクションは失敗しており、どのレジャーにも表示されません。検証済みのレジャー内に表示されるトランザクションの場合にのみ、結果は最終的なものとなります。それ以外の場合、このドキュメントで後述するように、`LastLedgerSequence`の制限により、表示されることはありません。
|
||||
|
||||
## XRP Ledgerプロトコル - コンセンサスと検証
|
||||
|
||||
ピアツーピアのXRP Ledgerネットワークは、トランザクションを承認して処理する多数の独立したXRP Ledgerサーバー（通常、[`rippled`](the-rippled-server.html)を実行）で構成されています。クライアントアプリケーションは、トランザクションに署名してXRP Ledgerサーバーに送信します。サーバーは、これらの候補トランザクションを処理するためにネットワーク内を中継します。クライアントアプリケーションには、モバイルおよびウェブウォレット、金融機関へのゲートウェイ、電子取引プラットフォームなどがあります。
|
||||
|
||||
[](img/xrp-ledger-network.ja.png)
|
||||
|
||||
_図4: XRP Ledgerプロトコルの参加者_
|
||||
|
||||
トランザクションを受信、中継、処理するサーバーは、追跡サーバーとバリデータのいずれかです。追跡サーバーの主な機能には、クライアントからのトランザクションの分散やレジャーに関する照会への応答が含まれます。検証サーバーは、追跡サーバーと同じ機能を実行し、さらにレジャーのシーケンスを進めます<a href="#footnote_3" id="from_footnote_3"><sup>3</sup></a>。
|
||||
|
||||
クライアントアプリケーションによって送信されたトランザクションを受け入れるときに、各追跡サーバーは最後に検証されたレジャーを開始点として使用します。受け入れられたトランザクションは候補トランザクションとなります。サーバーから候補トランザクションがそれぞれのピアに中継され、候補トランザクションがネットワーク全体に伝達されます。理想的には、各候補トランザクションはすべてのサーバーに伝達される必要があります。その結果、各サーバーは最後に検証されたレジャーに同じ一連のトランザクションを適用できる可能性が高くなります。しかし、トランザクションが伝達されるまでには時間がかかるため、サーバーは常に同じ候補トランザクションを処理するわけではありません。このことを考慮に入れて、XRP Ledgerでは、コンセンサスと呼ばれるプロセスを使用して、同一のトランザクションが処理され、ピアツーピアのXRP Ledgerネットワーク全体で検証済みのレジャーの一貫性が確保できるようにしています。
|
||||
|
||||
### コンセンサス
|
||||
|
||||
ネットワーク内のサーバーは、候補トランザクションに関する情報を共有します。コンセンサスプロセスを通じて、バリデータは、候補トランザクションの特定のサブセットが次のレジャーで考慮されることに同意します。コンセンサスとは、サーバーが提案や一連の候補トランザクションを中継する反復プロセスです。サーバーは、選択されたバリデータの過半数<a href="#footnote_4" id="from_footnote_4"><sup>4</sup></a>が同じ候補トランザクションのセットについて合意するまで、提案の通信と更新を行います。
|
||||
|
||||
コンセンサスの間、各サーバーは、そのサーバーの信頼できるバリデータ（_ユニークノードリスト（UNL）_）と呼ばれる特定のサーバー群からの提案を評価します。<a href="#footnote_5" id="from_footnote_5"><sup>5</sup></a>信頼できるバリデータとは、提案を評価するサーバーを欺こうと共謀しない、全体として「信頼できる」ネットワークのサブセットを表します。この「信頼」の定義では、選択された個々のバリデータが信頼されている必要はありません。バリデータの選択は、ネットワークに中継されたデータを改ざんする組織的な試みで共謀しないという想定に基づいて行われます<a href="#footnote_6" id="from_footnote_6"><sup>6</sup></a>。 <!-- STYLE_OVERRIDE: will -->
|
||||
|
||||
[](img/consensus-rounds.ja.png)
|
||||
|
||||
_図5: バリデータによるトランザクションセットの提案と修正 - コンセンサスの開始時点で、バリデータ毎に異なるトランザクションセットを持っている可能性があります。後のラウンドで、サーバーは現在の提案を信頼できるバリデータの提案と一致するように変更します。このプロセスでは、現在議論しているレジャーバージョンに適用するトランザクションと、それ以降のレジャーバージョンに適用するトランザクションを決定します。_
|
||||
|
||||
合意済みの提案に含まれていない候補トランザクションは、その後も候補トランザクションとして残ります。これらは次のレジャーバージョンで再度検討される可能性があります。通常、1つのレジャーバージョンから除外されたトランザクションは、次のレジャーバージョンに含まれます。
|
||||
|
||||
状況によっては、いつまでもコンセンサスに達することができないトランザクションもあります。そのような状況として、ネットワークが、必要な[トランザクションコスト](transaction-cost.html)を、トランザクションで指定されたものよりも高い値に変更している場合が考えられます。将来のある時点でこの手数料が引き下げられると、そのトランザクションが成功する可能性があります。トランザクションの成功または失敗が一定時間内に確定するように、トランザクションが特定のレジャーインデックスによって一定時間処理されない場合は期限切れになるように設定することができます。詳細については、[信頼できるトランザクションの送信](reliable-transaction-submission.html)を参照してください。
|
||||
|
||||
### 検証
|
||||
|
||||
検証は、全体のコンセンサスプロセスの第2段階です。このプロセスでは、すべてのサーバーで同じ結果が得られたことを確認し、あるレジャーバージョンが最終バージョンとして宣言されます。まれに、第一段階の[コンセンサスプロセスが失敗する場合](consensus-principles-and-rules.html#コンセンサス失敗の可能性)があります。検証によって後で確認が行われるため、サーバーは結果を確認し、それに応じて対処することができます。
|
||||
|
||||
検証は、大きく分けて次の2つの部分に分かれます。
|
||||
|
||||
- 合意済みのトランザクションセットから結果として生じるレジャーバージョンを計算する。
|
||||
- 結果を比較し、十分に信頼できるバリデータが同意した場合はレジャーバージョンの検証済みを宣言する。
|
||||
|
||||
#### 検証の計算と共有
|
||||
|
||||
コンセンサスプロセスが完了すると、各サーバーは合意済みの一連のトランザクションから新しいレジャーを個別に計算します。各サーバーは、同じ規則に従って結果を次のように計算します。
|
||||
|
||||
1. 一つ前の検証済みのレジャーから始めます。
|
||||
|
||||
2. すべてのサーバーが同じ方法で処理できるように、合意済みのトランザクションセットを _正規順序_ で並べ変えます。
|
||||
|
||||
[正規順序](https://github.com/ripple/rippled/blob/8429dd67e60ba360da591bfa905b58a35638fda1/src/ripple/app/misc/CanonicalTXSet.cpp#L25-L36)は、トランザクションを受け取った順序ではありません（サーバーが同じトランザクションを異なる順序で受け取る可能性があるため）。参加者がトランザクションの順序付けで競合しないように、故意に操作するのが困難な正規順序を使います。
|
||||
|
||||
3. 指示に従って、各トランザクションを順番に処理します。それに応じてレジャーの状態データを更新します。
|
||||
|
||||
トランザクションを正常に実行できない場合は、[`tec`クラス結果コード](tec-codes.html)を持つトランザクションを含めます。<a href="#footnote_1" id="from_footnote_1"><sup>1</sup></a>
|
||||
|
||||
特定の「再試行可能な」トランザクションの失敗に対しては、同じレジャーバージョンの他のトランザクションが実行された後に再試行されるように、そのトランザクションを正規順序の最後に移動します。
|
||||
|
||||
4. 適切なメタデータでレジャーヘッダーを更新します。
|
||||
|
||||
これには、レジャーインデックス、前に検証済みのレジャーの識別ハッシュ（このレジャーの「親」）、このレジャーバージョンの予定終了時刻、このレジャーの内容の暗号化ハッシュなどのデータが含まれます。
|
||||
|
||||
5. 新しいレジャーバージョンの識別用ハッシュを計算します。
|
||||
|
||||
|
||||
[](img/consensus-calculate-validation.ja.png)
|
||||
|
||||
_図7: XRP Ledgerサーバーでレジャー検証を計算する - 各サーバーは、同意済みのトランザクションを前の検証済みレジャーに適用します。バリデータは結果をネットワーク全体に送信します。_
|
||||
|
||||
#### 結果を比較する
|
||||
|
||||
バリデータはそれぞれ、計算したレジャーバージョンのハッシュを含む署名付きメッセージの形式で結果を中継します。 _検証_ と呼ばれるこれらのメッセージによって、各サーバーで計算したレジャーとそのピアのレジャーを比較することができます。
|
||||
|
||||
[](img/consensus-declare-validation.ja.png)
|
||||
|
||||
_図8: 過半数のピアが同じ結果を計算するとレジャーが検証される - 各サーバーは、計算されたレジャーを、選択されたバリデータから受け取ったハッシュと比較します。一致しない場合、サーバーは正しいレジャーを再計算または取得する必要があります。_
|
||||
|
||||
ネットワーク内のサーバーは、圧倒的多数のピアが同じ検証ハッシュに署名してそれをブロードキャストしたときに、そのレジャーインスタンスを検証済みと認識します <a href="#footnote_7" id="from_footnote_7"><sup>7</sup></a>。それ以降のトランザクションは、シーケンス番号N+1の更新および検証済みのこのレジャーに適用されます。
|
||||
|
||||
サーバーが少数で、ピアと異なるレジャーを計算した場合、計算したレジャーは無視されます<a href="#footnote_8" id="from_footnote_8"><sup>8</sup></a>。正しいレジャーを再計算するか、必要に応じて正しいレジャーを取得します。
|
||||
|
||||
ネットワークで、検証に関する過半数の同意が得られない場合、コンセンサスプロセスで一貫した提案を作成するにはトランザクション量が多すぎるか、ネットワーク遅延が大きすぎることを意味します。この場合、サーバーはコンセンサスプロセスを繰り返します。コンセンサスが始まってから時間が経過するにつれて、各コンセンサスラウンドで不一致は減少するため、過半数のサーバーが同じ候補トランザクションのセットを受け取った可能性が高くなります。XRP Ledgerは、これらの状況に応じて[トランザクションコスト](transaction-cost.html)と、コンセンサスを待つ時間を動的に調整します。
|
||||
|
||||
検証について過半数の合意が得られると、サーバーは検証済みの新しいレジャー、シーケンス番号N+1との作業に入ることができます。最後のラウンドに含まれなかった候補トランザクションと、その間に送信された新しいトランザクションに対して、コンセンサスと検証プロセスが繰り返されます<a href="#footnote_9" id="from_footnote_9"><sup>9</sup></a>。
|
||||
|
||||
|
||||
## 要点
|
||||
|
||||
XRP Ledgerに送信されたトランザクションはすぐには処理されません。一定期間、各トランザクションは候補状態になります。
|
||||
|
||||
単一トランザクションのライフサイクルは次のとおりです。
|
||||
|
||||
- アカウント所有者によってトランザクションが作成され、署名されます。
|
||||
- トランザクションがネットワークに送信されます。
|
||||
- 書式が正しくないトランザクションはその場で拒否される可能性があります。
|
||||
- 書式が正しいトランザクションは暫定的に成功し、その後で失敗する可能性があります。
|
||||
- 書式が正しトランザクションは暫定的に失敗し、その後で成功する可能性があります。
|
||||
- コンセンサスの間、トランザクションはレジャーに含まれます。
|
||||
- コンセンサスラウンドが成功すると、レジャーが有効になります。
|
||||
- コンセンサスラウンドが失敗すると、成功するまでコンセンサスプロセスが繰り返されます。
|
||||
- 検証済みレジャーには、トランザクションとレジャーの状態への反映が含まれます。
|
||||
|
||||
アプリケーションでは、候補トランザクションの暫定的な結果ではなく、検証済みのレジャーの情報のみを信頼してください。一部の[`rippled` API](rippled-api.html)では、トランザクションの暫定的な結果が最初に返されます。そのトランザクションが検証済みのレジャーに含まれている場合、またはトランザクションに`LastLedgerSequence`が含まれ、そのシーケンス番号以下の検証済みのレジャーにそのトランザクションが出現しない場合にのみ、トランザクションの結果は不変になります。
|
||||
|
||||
トランザクションを送信するアプリケーションのベストプラクティスは次のとおりです。
|
||||
|
||||
- `LastLedgerSequence`パラメーターを使用して、トランザクションが確定的かつ迅速な方法で検証されるか、失敗するようにします。
|
||||
- 検証されたレジャーでトランザクションの結果を確認します。
|
||||
- トランザクションを含むレジャーが検証されるか、`LastLedgerSequence`が経過するまで、結果は暫定的です。
|
||||
- 結果コードが**tesSUCCESS**で`"validated": true`のトランザクションは、恒久的に成功しています。
|
||||
- 結果コードがそれ以外の場合で`"validated": true`のトランザクションは、恒久的に失敗しています。
|
||||
- トランザクションの`LastLedgerSequence`によって識別された検証済みレジャーを含め、これまでの検証済みのレジャーに出現しないトランザクションは、恒久的に失敗しています。
|
||||
- このようなケースを検出するために、レジャーの継続的な履歴を有するサーバーを使用には注意してください<a href="#footnote_10" id="from_footnote_10"><sup>10</sup></a>。
|
||||
- `LastLedgerSequence`で識別されるレジャーが検証されるまで、トランザクションの状態を繰り返し確認する必要がある場合があります。
|
||||
|
||||
## その他のリソース
|
||||
|
||||
- [コンセンサスホワイトペーパー](https://ripple.com/files/ripple_consensus_whitepaper.pdf)
|
||||
- [レジャーフォーマットのリファレンス](ledger-data-formats.html)
|
||||
- [Ripple コンセンサスの動画](https://www.youtube.com/watch?v=pj1QVb1vlC0)
|
||||
- [信頼できるトランザクションの送信](reliable-transaction-submission.html)
|
||||
|
||||
|
||||
|
||||
## 脚注
|
||||
|
||||
<a href="#from_footnote_1" id="footnote_1"><sup>1</sup></a> – **tec**結果コードを含むトランザクションでは、リクエストされたアクションは実行されませんが、レジャーには影響します。ネットワークの悪用を防ぎ、トランザクションの分散コストを賄うために、XRPのトランザクションコストが消却されます。同じ送信者によって同時に送信された他のトランザクションをブロックしないようにするには、送信者のアカウントのシーケンス番号を都度増やしてゆきます。期限切れのオブジェクトや資金のない取引注文を削除するなどのメンテナンスも行います。
|
||||
|
||||
<a href="#from_footnote_2" id="footnote_2"><sup>2</sup></a> – 例えば、Aliceが100ドルを持っていて、全額をBobに送信するシナリオを考えてみましょう。アプリケーションは最初にPaymentトランザクションを送信し、Aliceの残高を確認したらすぐにAPIから0ドルが返されます。この値は、候補トランザクションの暫定結果に基づいています。支払いが失敗し、Aliceの残高が100ドルのままになる（または他のトランザクションによって別の金額になる）場合があります。AliceからBobへの支払いが成功したことを確実に知る唯一の方法は、そのトランザクションが検証済みのレジャー内にあり、かつ結果コードが**tesSUCCESS**になるまで、トランザクションの状況を確認することです。トランザクションが有効なレジャーにあるが、結果コードが異なる場合、支払いは失敗したことを意味します。
|
||||
|
||||
<a href="#from_footnote_3" id="footnote_3"><sup>3</sup></a> – 厳密に言えば、バリデータは追跡サーバーのサブセットです。同じ機能を提供することに加えて、「検証」メッセージを送信します。追跡サーバーは、レジャー履歴全体を保持しているか、部分的なレジャー履歴を保持しているかによって、さらに分類することができます。
|
||||
|
||||
<a href="#from_footnote_4" id="footnote_4"><sup>4</sup></a> – トランザクションを認識したピアの割合（%）がしきい値を下回った場合、コンセンサスのラウンドは失敗します。各ラウンドは反復プロセスです。第1ラウンドの開始時には、少なくともピアの50%が同意する必要があります。コンセンサスラウンドの最終的なしきい値は80%の合意です。これらの具体的な値は変更される可能性があります。
|
||||
|
||||
<a href="#from_footnote_5" id="footnote_5"><sup>5</sup></a> –各サーバーは独自の信頼できるバリデータを定義しますが、ネットワークの一貫性は、様々なサーバーで重複の度合いが高いバリデータのリストが選択されるかどうかにかかっています。このため、Rippleでは推奨するバリデータのリストを公開しています。
|
||||
|
||||
<a href="#from_footnote_6" id="footnote_6"><sup>6</sup></a> – 共謀しないとされるバリデータからだけでなくすべてのバリデータからの提案が評価される場合は、悪意のある攻撃者によって、無効なトランザクションが導入されたり、提案から有効なトランザクションが除外されたりする可能性があります。選択されたバリデータリストによって、[シビル攻撃](consensus-protections.html#シビル攻撃)から保護することができます。
|
||||
|
||||
<a href="#from_footnote_7" id="footnote_7"><sup>7</sup></a> – 2014年11月の時点で、圧倒的多数を表すしきい値として、少なくともピアの80%が検証すべきレジャーに同意する必要があります。これは、コンセンサスのラウンドで要求される割合と同じです。いずれのしきい値も変更される可能性があり、同じである必要はありません。
|
||||
|
||||
<a href="#from_footnote_8" id="footnote_8"><sup>8</sup></a> – 実際には、サーバーは自身が少数であることを検知してから、すべてのピアの検証を受け取ります。ピアの20%以上から不一致の検証を受け取ると、その検証がしきい値の80%を満たしていないことが分かります。その時点で、レジャーの再計算を始めることができます。
|
||||
|
||||
<a href="#from_footnote_9" id="footnote_9"><sup>9</sup></a> – 実際には、効率的に実行できるように、検証の完了前に新しいコンセンサスのラウンドが開始されます。
|
||||
|
||||
<a href="#from_footnote_10" id="footnote_10"><sup>10</sup></a> – `rippled`サーバーはレジャーの履歴全体がなくてもAPIリクエストに応答することができます。サービスやネットワーク接続が中断すると、そのサーバーのレジャー履歴にレジャーの不足や誤差が生じることがあります。時間の経過とともに、`rippled`によってその誤差は埋まります（そのように設定されている場合）。欠落しているトランザクションを検証する場合は、トランザクションが送信されてからLastLedgerSequenceまでの連続した完全なレジャーを持つサーバーに照らして検証することが重要です。特定のサーバーで利用できるcomplete_ledgersを判断するには、RPCサーバーの状態を使用します。
|
||||
40
content/concepts/consensus-network/fee-voting.ja.md
Normal file
40
content/concepts/consensus-network/fee-voting.ja.md
Normal file
@@ -0,0 +1,40 @@
|
||||
# 手数料投票
|
||||
|
||||
バリデータは、基本の[トランザクションコスト](transaction-cost.html)と[必要準備金](reserves.html)の変更について投票できます。バリデータの構成の設定がネットワークの現在の設定と異なる場合、バリデータはその設定をネットワークに定期的に公開します。定数のバリデータが変更に合意すると、変更を適用できるようになり、以後この変更が有効になります。バリデータはさまざまな理由から（特にXRPの価値の長期的な変化に適応するために）、この処理を行います。
|
||||
|
||||
[`rippled`バリデータ](run-rippled-as-a-validator.html)のオペレーターは、`rippled.cfg`ファイルの`[voting]`スタンザでトランザクションコストと必要準備金の設定を指定できます。
|
||||
|
||||
**注意:** 信頼できるバリデータの合意により不十分な必要準備金が採用された場合、XRP Ledgerピアツーピアネットワークがサービス拒否（DoS）攻撃を受ける可能性があります。
|
||||
|
||||
設定できるパラメーターは次の通りです。
|
||||
|
||||
| パラメーター | 説明 | 推奨される値 |
|
||||
|-----------|-------------|-------------------|
|
||||
| `reference_fee` | リファレンストランザクション（最も安価なトランザクション）を送信するときに消却する必要があるXRPの額（ _drop_ 単位）。（1 XRP = 100万drop）実際のトランザクションコストはこの値の数倍であり、個々のサーバーの負荷に基づいて動的に調整されます。 | `10` （0.00001 XRP） |
|
||||
| `account_reserve` | アカウントの準備金に必要なXRPの最小額（ _drop_ 単位）。これは、レジャーの新しいアカウントへの資金供給のために送金できる最小額です。 | `20000000` （20 XRP） |
|
||||
| `owner_reserve` | アドレスがレジャーで所有するオブジェクト _ごと_ に必要なXRPの額（ _drop_ 単位）。 | `5000000` （5 XRP） |
|
||||
|
||||
## 投票プロセス
|
||||
|
||||
256番目の各レジャーは「フラグ」レジャーと呼ばれます。（フラグレジャーは`ledger_index` [modulo](https://en.wikipedia.org/wiki/Modulo_operation) `256`が`0`になるように定義されています。）フラグレジャーの直前のレジャーでは、アカウント準備金またはトランザクションコストの設定が現行のネットワーク設定と異なる各バリデータは、そのレジャー検証とともに「投票」メッセージを配信し、バリデータが希望する値を示します。
|
||||
|
||||
フラグレジャー自体では何も起こりませんが、バリデータは信頼する他のバリデータからの投票を受信して記録します。
|
||||
|
||||
他のバリデータの投票を集計した後、各バリデータは自身の設定と信頼する過半数のバリデータの設定の間で妥協点を探ります。（たとえば、あるバリデータが最小トランザクションコストを10から100に引き上げることを望む一方で、ほとんどのバリデータは10から20に引き上げることを望んでいる場合、そのバリデータは当該のコストを20に引き上げることにします。ただし、そのバリデータは10未満の値または100を超える値にすることはありません。）妥協できる場合、バリデータはフラグレジャーの直後のレジャーに対する提案に[SetFee疑似トランザクション](setfee.html)を挿入します。同じ変更を求める他のバリデータは、同じレジャーに対する各自の提案に同じSetFee疑似トランザクションを挿入します。（設定が既存のネットワーク設定と一致している場合、バリデータは何も行いません。）SetFee疑似トランザクションがコンセンサスプロセスを通過し、検証済みレジャーに追加される場合、SetFee疑似トランザクションで設定された新しいトランザクションコストと準備金の設定がその次のレジャーから有効になります。
|
||||
|
||||
まとめ:
|
||||
|
||||
* **フラグレジャー-1**: バリデータが投票を送信します。
|
||||
* **フラグレジャー**: バリデータが投票を集計し、どのSetFeeの内容を含めるか決定します（存在する場合）。
|
||||
* **フラグレジャー+1**: バリデータは、SetFee疑似トランザクションを各自の提案レジャーに挿入します。
|
||||
* **フラグレジャー+2**: SetFee疑似トランザクションがコンセンサスに達すると、新しい設定が有効になります。
|
||||
|
||||
## 手数料の最大値
|
||||
|
||||
手数料の最大可能値は、[FeeSettingsレジャーオブジェクト](feesettings.html)に保管されている内部データ型により制限されます。これらの値は次のとおりです。
|
||||
|
||||
| パラメーター | 最大値（drop） | 最大値（XRP）
|
||||
|-----------|-----------------------|----|
|
||||
| `reference_fee` | 2**64 | （これまでに存在したXRP総額よりも大きい） |
|
||||
| `account_reserve` | 2^32 drop | 約4294 XRP |
|
||||
| `owner_reserve` | 2^32 drop | 約4294 XRP |
|
||||
13
content/concepts/consensus-network/parallel-networks.ja.md
Normal file
13
content/concepts/consensus-network/parallel-networks.ja.md
Normal file
@@ -0,0 +1,13 @@
|
||||
# 並列ネットワーク
|
||||
|
||||
大抵の場合、XRP Ledgerは1つの集合体であると説明され、これはほぼ真実です。本番環境のXRP Ledgerピアツーピアネットワークが1つ存在し、XRP Ledgerに記録されるすべての取引はその本番環境のネットワーク内で発生します。
|
||||
|
||||
ただし、場合によってはコアネットワークとの通信なしでテストや実験を行うことが求められます。このため、Rippleは「代替環境の」ネットワークとして[Ripple Test Net](xrp-test-net-faucet.html)を開始しました。Ripple Test Netは、XRP Ledgerユーザーによるビジネス処理に影響を及ぼすことなく、アプリケーションや`rippled`サーバー自体をテストできる環境として機能します。Ripple Test Net（AltNetとも呼ばれます）にはTestNet専用のXRPが供給されています。Rippleは、Test Netでのアプリケーション開発に関心のある当事者にこのTestNet専用XRPを[無料で提供](xrp-test-net-faucet.html)しています。
|
||||
|
||||
**注意:** Rippleはテストネットワークの安定性について一切保証しません。テストネットワークは、サーバー構成、ネットワークトポロジー、ネットワークパフォーマンスのさまざまな特性をテストする目的でこれまで使用され、またこれからも同様に使用されます。
|
||||
|
||||
今後は、特定の目的向けに小規模な臨時テストネットワークも導入される可能性があります。
|
||||
|
||||
## 並列ネットワークとコンセンサス
|
||||
|
||||
使用するネットワークを定義する`rippled`の設定はありません。その代わり、信頼するバリデータのコンセンサスに基づいてどのレジャーを正しいレジャーとして受け入れるかを把握します。`rippled`インスタンスからなる異なるコンセンサスグループが、同じグループの他のメンバーだけを信頼する場合、各グループは引き続き並列ネットワークとして機能します。悪意のあるコンピューターや不適切に動作するコンピューターが両方のネットワークに接続している場合でも、各ネットワークのメンバーが、定数設定を超えて別のネットワークのメンバーを信頼するように設定されていない限り、コンセンサスプロセスに混乱は生じません。
|
||||
@@ -0,0 +1,147 @@
|
||||
# トランザクション展性
|
||||
|
||||
署名後のトランザクションを、署名に使用されたキーを使用せずに変更できる場合、そのトランザクションには「展性がある」ことになります。XRP Ledgerでは、署名付きトランザクションの**機能性**は変更できませんが、場合によっては第三者がトランザクションの署名と識別用ハッシュを変更できる _可能性があります_ 。
|
||||
|
||||
展性のあるトランザクションは元のハッシュでのみ実行できると想定して、脆弱なソフトウェアが展性のあるトランザクションを送信した場合、トランザクションの状況を把握できなくなる可能性があります。最悪の場合、不正使用者がこの点を悪用して脆弱なシステムから資金を盗むことが可能です。
|
||||
|
||||
次の2つの状況は、トランザクション展性の問題につながる可能性があります。
|
||||
|
||||
1. デフォルトの署名アルゴリズム（ECDSAとsecp256k1曲線）を使用して署名されたトランザクションにtfFullyCanonicalSigフラグが指定されていない。
|
||||
|
||||
**[tfFullyCanonicalSigフラグ](transaction-common-fields.html#グローバルフラグ)を使用** して、トランザクションに展性がないことを保証します。[Ed25519キーで署名されている](cryptographic-keys.html#署名アルゴリズム)トランザクションはこの問題に対して脆弱ではありませんが、 _すべての_ トランザクションにこのフラグを使用しても **特に不都合はありません** 。
|
||||
|
||||
2. トランザクションが[マルチ署名済み](multi-signing.html)であり、署名の数が必要以上に多い場合。元々トランザクションに必要な数を上回る署名がされていなかった場合でも、権限のある署名者が追加の署名を提供すると、このトランザクションが展性を得ることがあります。
|
||||
|
||||
適切な運用セキュリティ対策を導入することで、このような問題を防ぐことができます。ガイドラインについては、[マルチ署名の展性の緩和対策](#マルチ署名の展性の緩和対策)を参照してください。
|
||||
|
||||
|
||||
## 背景
|
||||
|
||||
XRP Ledgerでは、以下の条件に該当しない場合にはトランザクションを実行できません。
|
||||
|
||||
- 署名自体を除く[トランザクションのすべてのフィールド](transaction-common-fields.html)に署名がなされている。
|
||||
- トランザクションの署名に使用されるキーペアが、[そのアカウントの代理としてトランザクションを送信することが承認されている](transaction-basics.html#取引の承認)。
|
||||
- 署名は _正規_ であり、トランザクションの指示に一致している。
|
||||
|
||||
署名付きフィールドに変更を加えると、どれほど小さな変更であっても署名が無効となるため、署名自体を除き、トランザクションのいかなる部分にも展性が生じることはありません。ほとんどの場合、署名自体を変更すると常に署名が無効になりますが、以下で説明するような特定の例外があります。
|
||||
|
||||
署名はトランザクションの識別用ハッシュの計算に使用されるデータの1つであるため、展性のあるトランザクションを変更すると、ハッシュ値が変わります。
|
||||
|
||||
### 代替secp256k1署名
|
||||
|
||||
「正規」であるためには、ECDSAアルゴリズムとsecp256k1曲線（デフォルト）を使用して作成された署名が以下の要件を満たしている必要があります。
|
||||
|
||||
- 署名が適切な[DERエンコードデータ](https://en.wikipedia.org/wiki/X.690#DER_encoding)である必要があります。
|
||||
- 署名ではDERエンコードデータ外部に埋め込みバイトがあってはなりません。
|
||||
- 署名を構成する整数はマイナスであってはならず、またsecp256k1係数以下でなければなりません。
|
||||
|
||||
一般に、あらゆる標準ECDSA実装ではこれらの要件が自動的に処理されます。ただしsecp256k1では、展性を防ぐにはこれらの要件では不十分です。したがってXRP Ledgerでは、同様の問題がない「完全に正規である」署名という概念を採用しています。
|
||||
|
||||
ECDSA署名はRおよびSと呼ばれる2つの整数で構成されています。secp256k1係数はNと呼ばれ、すべてのsecp256k1署名の定数です。具体的にはNは値`0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141`です。署名`(R,S)`では、署名`(R, N-S)`（Sの位置にN-Sを使用）も有効です。
|
||||
|
||||
このように、 _完全に_ 正規である署名を使用する場合には、2つの有効な値のうちどちらを使用するかを選択し、もう一方が無効であることを宣言する必要があります。XRP Ledgerの作成者は、2つの有効な値（`S`と`N-S`）のいずれか _小さい方_ を任意に選択すると決めました。トランザクションが選択された（小さな）値`S`を使用し、正規トランザクションとなるためのすべての標準ルールに準拠している場合、このトランザクションは _完全に正規_ であるとみなされます。
|
||||
|
||||
完全に正規である署名の生成が確実に行われていなかった古いソフトウェアとの互換性を維持するため、XRP Ledgerは完全に正規ではないトランザクションも受け入れます。新しいユーザーを悪用から保護するため、XRP Ledgerではトランザクション向けに[**tfFullyCanonicalSig**](transaction-common-fields.html#グローバルフラグ)というフラグがあります。このフラグが設定されている場合、トランザクションが有効となるには _完全に正規_ の署名を使用する必要があります。
|
||||
|
||||
完全に正規であるECDSA署名を計算するには、SとN-Sを比較していずれが小さいかを見極めて、トランザクションの`Signature`フィールドにその値を使用する必要があります。
|
||||
|
||||
Rippleが公開しているすべてのXRP Ledgerソフトウェア（`rippled`およびripple-lib/RippleAPIを含む）では、完全に正規である署名のみが生成されます。ユーザーの保護を強化するため、Rippleは、可能な限りデフォルトで**tfFullyCanonicalSig**フラグを有効にするようにコードを構成しています。XRP Ledgerソフトウェアのサードパーティ実装においても、完全に正規である署名だけを生成し、デフォルトでトランザクションのtfFullyCanonicalSigが有効にすることを強く推奨します。
|
||||
|
||||
次の2つの状況においては、RippleのXRP Ledgerの署名実装によってtfFullyCanonicalSigフラグが自動的に有効になりません。次の状況では、フラグを慎重に設定する必要があります。
|
||||
|
||||
- ユーザーがトランザクションの`Flags`フィールドを明示的に指定している場合。ビット単位のORを使用してtfFullyCanonicalSig _と_ その他の必要なすべてのフラグを適用します。
|
||||
- ユーザーがトランザクションにマルチ署名を提供する場合。マルチ署名の複数の参加者は _厳密に_ 同一のデータに署名する必要があるので、署名コードはtfFullyCanonicalSigフラグを追加するというトランザクションの指示を事前に処理しません。マルチ署名済みトランザクションでは、常にtfFullyCanonicalSigフラグを明示的に有効にしてください。
|
||||
|
||||
|
||||
### マルチ署名の展性
|
||||
|
||||
マルチ署名の明示的で重要な機能として、さまざまな設定によってトランザクションを有効にできるという機能があげられます。たとえば、5人の署名者のうち3人の署名者の署名によってトランザクションを承認できるようにアカウントを設定できます。ただしこの場合、有効なトランザクションにはいくつかのバリエーションが存在する可能性があり、識別用ハッシュは各バリエーションごとに異なります。
|
||||
|
||||
以下のケースはすべて、トランザクション展性の問題につながる可能性があります。
|
||||
|
||||
- トランザクションへの署名を1つ以上を削除しても、まだその定数を満たすのに十分な数の署名がある場合。第三者が署名を削除し、署名なしでトランザクションを再送信できる可能性があります。
|
||||
- すでに定数に達しているトランザクションに有効な署名を追加できる場合。このような署名を作成できるのは、送信側アカウントの権限のある署名者だけです。
|
||||
- 定数を維持しながら、あるトランザクションの署名を、別の有効な署名に置き換えることができる場合。このような署名を作成できるのは、送信側アカウントの権限のある署名者だけです。
|
||||
|
||||
権限のある署名者に意図的な悪意がない場合でも、混乱や不適切な調整が原因で、複数の署名者が同じトランザクションの異なる有効バージョンを送信することがあります。
|
||||
|
||||
#### マルチ署名の展性の緩和対策
|
||||
|
||||
**適切な運用セキュリティ対策を導入することで、このような問題を防ぐことができます。** 通常、以下のような適切な運用セキュリティ対策に従っていれば、マルチ署名でのトランザクション展性の問題を防ぐことができます。
|
||||
|
||||
- 必要な数以上の署名を収集しない。
|
||||
- 必要な数の署名を収集した後でトランザクションを作成する当事者を任命するか、または署名者が事前に定義された順序でトランザクション指示に署名して次に渡せるように「チェーン」を指定する。
|
||||
- マルチ署名リストに不要な署名者または信頼できない署名者を追加しない。これは、これらの署名者のキーに関連付けられている`weight`の値が、トランザクションの承認には不十分である場合にも該当する。
|
||||
- トランザクションが異なるハッシュまたは想定外の署名セットを使用して実行される可能性に対処できるよう備える。アカウントから送信されたトランザクションを注意深く監視する（[account_txメソッド][]などを使用）。
|
||||
- アカウントの`Sequence`番号を監視する（[account_infoメソッド][]などを使用）。この番号は、アカウントがトランザクションを正常に送信するたびに1ずつ増えますが、それ以外の状況で増えることはありません。番号が想定した番号と一致しない場合は、最近のトランザクションを調べてその原因を確認します。（展性のあるトランザクションの他にも、このような状況が発生することがあります。たとえばトランザクションを送信するように別のアプリケーションを設定する場合などです。不正使用者が秘密鍵にアクセスした可能性もあります。あるいは、アプリケーションでデータが失われ、送信済みのトランザクションが忘れられた可能性もあります。）
|
||||
- トランザクションを再度作成してマルチ署名済みにする場合は、目的の処理がまだ実行されていないことを手動で確認している場合を除き、`Sequence`番号を変更 _しないでください_ 。
|
||||
- 署名前にtfFullyCanonicalSigフラグが有効であることを確認する。
|
||||
|
||||
セキュリティ強化のため、上記のガイドラインにより何重もの保護対策が講じられます。
|
||||
|
||||
|
||||
## 展性のあるトランザクションを使用した悪用
|
||||
|
||||
XRP Ledgerとのインフターフェイスに使用するソフトウェアから展性のあるトランザクションが送信されると、不正使用者がソフトウェアをだましてトランザクションの最終結果を確認できなくし、（最悪の場合）同額の支払いを複数回送金させることが可能になります。
|
||||
|
||||
シングルシグネチャーを使用していて、tfFullyCanonicalSigフラグを常に有効にしている場合には、このような悪用に対し脆弱ではありません。マルチ署名を使用していて、署名者が必要な数を超える署名を提供する場合には脆弱になります。
|
||||
|
||||
### 悪用シナリオの流れ
|
||||
|
||||
脆弱なシステムを悪用するプロセスは、以下のような順で進みます。
|
||||
|
||||
1. 脆弱なシステムが、tfFullyCanonicalSigを有効にせずにトランザクションを生成し署名する。
|
||||
|
||||
トランザクションでtfFullyCanonicalSigフラグが有効に設定されない状況として以下の3つがあります。
|
||||
|
||||
- システムが`Flags`フィールドを明示的に指定し、このフィールドでtfFullyCanonicalSigビットが有効になっていない。
|
||||
- トランザクションがマルチ署名済みであり、tfFullyCanonicalSigフラグが明示的に有効にされていない。
|
||||
- システムでトランザクションのフィールドから`Flags`フィールドが省略されているが、署名時にtfFullyCanonicalSigを自動的に有効にしない非標準の実装が使用されている。
|
||||
|
||||
トランザクションがECDSAキーペアで署名されている場合、そのトランザクションは脆弱になります。マルチ署名済みの場合、トランザクションの署名に少なくとも1つのECDSAキーペアが使用される必要があります。
|
||||
|
||||
ほとんどの場合、脆弱なトランザクションには完全に正規である署名が使用されていますが、トランザクションが完全に正規ではない署名を使用していても、フラグはそのトランザクションが有効であると示します。また、限られた時間内に最終結果が判かるように、トランザクションで`LastLedgerSequence`が使用されていることもあります。
|
||||
|
||||
2. システムは脆弱なトランザクションの識別用ハッシュを確認し、そのハッシュをXRP Ledgerネットワークに送信し、検証済みレジャーバージョンにそのハッシュが記録されるのを監視し始めます。
|
||||
|
||||
3. 不正使用者は、トランザクションが確定する前にそのトランザクションがネットワークを通じて伝搬することを確認します。
|
||||
|
||||
4. 不正使用者が脆弱なトランザクションの代替署名を計算します。
|
||||
|
||||
異なるトランザクション指示の署名を作成する場合とは異なり、この場合は大量の計算処理は不要です。最初に署名を生成する場合よりもかなり短い時間で完了する可能性があります。
|
||||
|
||||
改ざんされた署名により、異なる識別用ハッシュが生成されます。（ネットワークに送信する前にハッシュを計算する必要はありませんが、ハッシュがあれば後でトランザクションのステータスを容易に確認できることを理解しています。）
|
||||
|
||||
5. 不正使用者が改ざんした（完全に正規ではない可能性のある）トランザクションをネットワークに送信します。
|
||||
|
||||
これにより、当初送信されたトランザクションと、不正使用者によって送信された改ざんバージョンが「競争」します。この2つのトランザクションが同時に記録されることはありません。いずれのトランザクションも有効ですが、`Sequence`番号をはじめ厳密に同一のトランザクションデータを含んでいるので、検証済みレジャーに記録できるのは常にいずれか1つになります。
|
||||
|
||||
ピアツーピアネットワークのサーバーは、どちらが「最初に到着した」トランザクションであるか、またはどちらが元の送信者が意図したトランザクションであるかを認識できません。ネットワーク接続での遅延やその他の偶発的な事象により、バリデータはコンセンサス提案をファイナライズする時点で、いずれかのトランザクションだけを認識する結果になる可能性があります。この場合、いずれかのトランザクションが「競争に勝った」ことになります。
|
||||
|
||||
もし不正使用者がピアツーピアネットワークで適切に接続しているいくつかのサーバーを乗っ取れば、これらのサーバーがバリデータとして信頼されていなくても、非正規トランザクションを確定できる確率を高めることができます。
|
||||
|
||||
脆弱なシステムからのトランザクションを唯一受信したサーバーを不正使用者が乗っ取った場合、不正使用者はネットワークの他の部分に配信されるバージョンを容易に制御できるようになります。
|
||||
|
||||
6. 不正ユーザーのトランザクションがコンセンサスに達し、検証済みレジャーに記録されます。
|
||||
|
||||
この時点でトランザクションは実行されており、このトランザクションを無効にすることはできません。その影響（XRPの送金など）は最終的です。本来のトランザクションは、その`Sequence`番号がすでに使用されているために有効ではなくなります。
|
||||
|
||||
XRP Ledgerでのトランザクションの影響は、本来のバージョンが実行された場合とまったく同じです。
|
||||
|
||||
7. 脆弱なシステムは、予期しているトランザクションハッシュを認識せず、トランザクションが実行されなかったという誤った結論に達します。
|
||||
|
||||
トランザクションに`LastLedgerSequence`フィールドが含まれている場合は、指定されたレジャーインデックスを経過した後でこの状況が発生します。
|
||||
|
||||
トランザクションで`LastLedgerSequence`フィールドが省略されている場合は、別の意味で誤っている可能性があります。つまり、同じ送信者からの他のトランザクションでは同じ`Sequence`番号が使用されていない場合、トランザクションはその後、時間の経過に関係なく、理論上成功します。（詳細は、[確実なトランザクションの送信](reliable-transaction-submission.html)を参照してください。）
|
||||
|
||||
8. 脆弱なシステムは、トランザクションが失敗したと想定してアクションを実行します。
|
||||
|
||||
たとえば、XRP Ledgerで送金されていないと判断した資金についての責任を果たすため、システムで顧客の残高に返金します（または単に引き落としを行いません）。
|
||||
|
||||
さらに、脆弱なシステムがトランザクションを置き換えるために新しいトランザクションを生成し、ネットワークの現在の状態に基づいて新しい`Sequence`、`LastLedgerSequence`、および`Fee`パラメーターを選択し、その一方でトランザクションの残りの部分は本来のトランザクションと同じ状態で維持することがあります。この新しいトランザクションにも展性がある場合、システムは何度も同じように悪用される可能性があります。
|
||||
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
73
content/concepts/consensus-network/transaction-queue.ja.md
Normal file
73
content/concepts/consensus-network/transaction-queue.ja.md
Normal file
@@ -0,0 +1,73 @@
|
||||
# トランザクションキュー
|
||||
|
||||
`rippled`サーバーは、トランザクションキューを使用して[オープンレジャーコスト](transaction-cost.html#オープンレジャーコスト)を適用します。オープンレジャーコストにより、特定のレジャーの目標トランザクション数が設定され、オープンレジャーがこのサイズを超えると、必要なトランザクションコストが迅速に引き上げられます。`rippled`は引き上げられたトランザクションコストを支払うことができないトランザクションを無効にする代わりに、次のレジャーの構築に使用するトランザクションキューにそれらのトランザクションを入れようとします。
|
||||
|
||||
## トランザクションキューとコンセンサス
|
||||
|
||||
トランザクションキューは、コンセンサスプロセスで特定のレジャーバージョンに記録されるトランザクションと除外されるトランザクションを選択する際に、重要な役割を果たします。以下のステップでは、トランザクションキューと[コンセンサスプロセス](consensus.html)の関係を説明します。
|
||||
|
||||
[](img/consensus-with-queue.ja.png)
|
||||
|
||||
1. **コンセンサスラウンド1** - 各バリデータが、次のレジャーバージョンに記録するトランザクションセットを提案します。各バリデータは、現在提案されていないトランザクション候補のキューも保持します。
|
||||
|
||||
2. **コンセンサスラウンド2** - バリデータは後のラウンドで自身の提案からトランザクションを削除する場合、そのトランザクションをキューに追加します。
|
||||
|
||||
3. **コンセンサスラウンドN** - 十分な数のサーバーがトランザクションセットについて合意するまで、コンセンサスプロセスが継続されます。
|
||||
|
||||
4. **検証** - 複数のサーバーが、各々同一のレジャーを構築したことを確認し、そのレジャーが検証済みであると宣言します。
|
||||
|
||||
5. **次の提案の作成** - 各バリデータは、キューに入れられているトランザクションを最初に使用して、次のレジャーバージョンの提案を準備します。
|
||||
|
||||
6. **キューへの追加** - 次の提案レジャーがすでにいっぱいである場合は、着信トランザクションはその後のレジャーバージョンのキューに入れられます。（[オープンレジャーコスト](transaction-cost.html#オープンレジャーコスト)を支払うトランザクションは、次の提案レジャーが「いっぱい」であってもそのレジャーに追加されますが、このようにトランザクションが追加されるたびにオープンレジャーコストは急激に増加します。）
|
||||
|
||||
このステップの後、プロセスが最初から繰り返されます。
|
||||
|
||||
**注記:** 技術的には、上記のプロセスで説明したステップのいくつかは並行して発生します。これは、各サーバーは常に新しいトランザクションに備えて待機しており、前のレジャーバージョンのコンセンサスプロセスの実行中に次のレジャー提案の準備を開始するためです。
|
||||
|
||||
## キューの制約事項
|
||||
|
||||
`rippled`サーバーはさまざまな経験則によるテストを行って「レジャーに追加される可能性がある」トランザクションを推定します。現行の実装では、以下のルールに基づいてキューに入れるトランザクションが決定されます。
|
||||
|
||||
- トランザクションは適切な形式で作成され、有効な署名によって[承認](transaction-basics.html#取引の承認)されている必要があります。
|
||||
- `AccountTxnID`フィールドが指定されているトランザクションはキューに入れることができません。
|
||||
- 1つの送信側アドレスには、同時に最大10個のトランザクションを入れることができます。
|
||||
- トランザクションをキューに入れるには、送信者が以下のすべてを行うのに十分なXRPを保有している必要があります。[更新: rippled 1.2.0][]
|
||||
- キュー内のすべての送信者のトランザクションの`Fee`フィールドに指定されているXRP[トランザクションコスト](transaction-cost.html)の消却。キュー内のトランザクションの合計額は、アカウントの基本準備金（現時点では20 XRP）を超えることはできません。（トランザクションコストの支払いが最小額の0.00001 XRPを大幅に上回るトランザクションは、キューをスキップし、オープンレジャーに直接追加されます。）
|
||||
- キュー内のすべての送信者のトランザクションの送金を可能とするXRPの最大合計額の送信。
|
||||
- アカウントの[必要準備金](reserves.html)を確保するのに十分なXRPの保有。
|
||||
- あるトランザクションが、送信側アドレスがトランザクションを承認する方法に影響する場合、同じアドレスからの他のトランザクションをそのトランザクションの後にキューに入れることはできません。[新規: rippled 0.32.0][]
|
||||
- トランザクションに`LastLedgerSequence`フィールドが指定されている場合、そのフィールドの値は少なくとも **現在のレジャーインデックス+ 2**になります。
|
||||
|
||||
### 手数料の平均化
|
||||
|
||||
[新規: rippled 0.33.0][]
|
||||
|
||||
送信側アドレスのキューに1つ以上のトランザクションが入っている場合、その送信者はキューに入れられている既存のトランザクションをオープンレジャーに「プッシュ」するため、それらすべてのトランザクションのトランザクションコストの支払いをするのに十分なトランザクションコストが指定された新しいトランザクションを送信します。具体的には、新しいトランザクションは、そのトランザクション自体と、そのトランザクションより先にキュー内に入れられている同じ送信者からの各トランザクションの[オープンレジャーコスト](transaction-cost.html#オープンレジャーコスト)をカバーするのに十分なトランザクションコストを支払う必要があります。（オープンレジャーコストは、トランザクションがトランザクションコストを支払うたびに急激に増加することに留意してください。）トランザクションは他の[キューの制約事項](#キューの制約事項)にも従い、送信側アドレスはキュー内のすべてのトランザクションのトランザクションコストを支払うのに十分な額のXRPを保有している必要があります。
|
||||
|
||||
この機能により、特定の状況を回避できます。キュー内にある低コストのトランザクションを1つ以上送信した場合、同じアドレスから新しいトランザクションを送信するには、以下のいずれかを実行する必要があります。
|
||||
|
||||
* キュー内のトランザクションが検証済みレジャーに追加されるまで待機する。
|
||||
* キュー内のトランザクションに[`LastLedgerSequence`フィールド](reliable-transaction-submission.html#lastledgersequence)が設定されている場合、それらのトランザクションが完全に無効化されるまで待機する。
|
||||
* [キュー内のトランザクションを取り消す](cancel-or-skip-a-transaction.html)。このためには、同じシーケンス番号で、これらのトランザクションよりも高いトランザクションコストを指定した新しいトランザクションを送信します。
|
||||
|
||||
上記のどの操作も行われないと、トランザクションは理論上無期限にキューに入れられたままとなり、他の送信者はそれらよりもトランザクションコストが高いトランザクションを送信してキューに「割り込む」ことができます。署名済みのトランザクションは変更できないため、キュー内のトランザクションのトランザクションコストを増加して、トランザクションの優先度を上げることはできません。以前に送信されたトランザクションを無効にしたくない場合には、手数料の平均化が回避策となります。新しいトランザクションのトランザクションコストを増額して不足分を補えば、キュー内のトランザクションは即時にオープンレジャーに追加されます。
|
||||
|
||||
## キュー内の順序
|
||||
|
||||
トランザクションキュー内では、最も高いトランザクションコストを支払うトランザクションが一番になるようにトランザクションがランク付けされています。このランク付けはトランザクションの _絶対_ XRPコストではなく、 _[該当するトランザクションタイプの最小コスト](transaction-cost.html#特別なトランザクションコスト)に相対的な_ コストに基づいています。トランザクションコストが同額のトランザクションが複数ある場合は、サーバーが受信した順にランク付けされます。キュー内のトランザクションの順序にはその他の要因も影響します。たとえば、同一送信者からのトランザクションはその`Sequence`番号によりソートされ、順に送信されます。
|
||||
|
||||
キュー内のトランザクションの数が次のレジャーバージョンの予期サイズを超える場合には、キュー内のトランザクションの正確な順序に基づいて、次の処理レジャーバージョンに追加されるトランザクションが決定します。トランザクションの順序は**検証済みレジャー内でのトランザクションの実行順序には影響しません**。各検証済みレジャーバージョンでは、そのバージョンのトランザクションセットが[正規の順序](consensus.html#検証の計算と共有)で実行されます。
|
||||
|
||||
**注記:**`rippled`がトランザクションをキューに入れるときに付与される暫定的な[トランザクション応答コード](transaction-results.html)は`terQUEUED`です。つまり、トランザクションは今後のレジャーバージョンで成功する見込みです。すべての暫定的な応答コードと同様に、トランザクションが検証済みレジャーに追加されるか、または[完全に無効であると示される](finality-of-results.html)までは、トランザクションの結果は最終的ではありません。
|
||||
|
||||
|
||||
## 関連項目
|
||||
|
||||
- トランザクションコストが設けられている理由と、XRP Ledgerでのトランザクションコストの適用方法については、[トランザクションコスト](transaction-cost.html)を参照してください。
|
||||
- コンセンサスプロセスによるトランザクション承認方法についての詳しい説明は、[コンセンサス](consensus.html)を参照してください。
|
||||
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -31,7 +31,7 @@ The `rippled` server uses a variety of heuristics to estimate which transactions
|
||||
- Transactions must be properly-formed and [authorized](transaction-basics.html#authorizing-transactions) with valid signatures.
|
||||
- Transactions with an `AccountTxnID` field cannot be queued.
|
||||
- A single sending address can have at most 10 transactions queued at the same time.
|
||||
- To queue a transaction, the sender must have enough XRP for all of the following: [Updated in: rippled 1.2.0][New in: rippled 1.2.0]
|
||||
- To queue a transaction, the sender must have enough XRP for all of the following: [Updated in: rippled 1.2.0][]
|
||||
- Destroying the XRP [transaction cost](transaction-cost.html) as specified in the `Fee` fields of all the sender's queued transactions. The total amount among queued transactions cannot be more than the base account reserve (currently 20 XRP). (Transactions paying significantly more than the minimum transaction cost of 0.00001 XRP typically skip the queue and go straight into the open ledger.)
|
||||
- Sending the maximum sum of XRP that all the sender's queued transactions could send.
|
||||
- Keeping enough XRP to meet the account's [reserve requirements](reserves.html).
|
||||
|
||||
13
content/concepts/decentralized-exchange/autobridging.ja.md
Normal file
13
content/concepts/decentralized-exchange/autobridging.ja.md
Normal file
@@ -0,0 +1,13 @@
|
||||
# オートブリッジング
|
||||
|
||||
XRP以外の2種類の通貨を交換するOfferCreateでは、合成されたオーダーブックでXRPが中間通貨として使用されることがあります。これは、XRPを媒介通貨として使用することであらゆる通貨ペアの流動性を改善するオートブリッジング機能によるものです。XRP Ledgerのネイティブ暗号資産であるというXRPの特性によりこのように機能します。オファーを実行する際は、直接オファーとオートブリッジングオファーを組み合わせることで全体として最良の為替レートを実現できます。
|
||||
|
||||
例: _AnitaはGBPを売却してBRLを購入するオファーを発行しました。このような一般的ではない通貨マーケットでは、オファーがあまりない場合があります。良いレートのオファーが1件ありますが、Anitaの取引を満たすのに十分な量ではありません。ただしGBPとXRPおよびBRLとXRPの間には、それぞれアクティブで競争力のあるマーケットが存在します。オートブリッジングソフトウェアは、Anitaのオファーを履行できる方法を見つけるため、あるトレーダーからXRPをGBPで購入し、別のトレーダーにXRPを支払ってBRLを購入します。AnitaはGBPとBRLを直接交換するマーケットでの少額オファーを、GBP対XRPのオファーとXRP対BRLのオファーをペアリングしてより良い複合レートと組み合わせて、最適なレートを自動的に得ることができます。_
|
||||
|
||||
OfferCreateトランザクションではオートブリッジングが常に自動的に行われます。[Paymentトランザクション](payment.html)ではオートブリッジングはデフォルトで _行われません_ が、path-findingにより同様の効果のあるパスを検索できます。
|
||||
|
||||
## 参照項目
|
||||
|
||||
- [Dev Blog: Introducing Autobridging](https://ripple.com/dev-blog/introducing-offer-autobridging/)
|
||||
|
||||
- [オファーの優先度](offers.html#オファーの優先度)
|
||||
75
content/concepts/decentralized-exchange/offers.ja.md
Normal file
75
content/concepts/decentralized-exchange/offers.ja.md
Normal file
@@ -0,0 +1,75 @@
|
||||
# オファー
|
||||
|
||||
XRP Ledgerの分散型取引所では、通貨の取引注文は「オファー」と呼ばれます。オファーはXRPと発行済み通貨の取引、または発行済み通貨間の取引（同一通貨コードだがイシュアーが異なる発行済み通貨を含む）を行うことができます。（同一コードでイシュアーが異なる通貨は、[rippling](rippling.html)によって取引することもできます。）
|
||||
|
||||
- オファーを作成するには、[OfferCreateトランザクション][]を送信します。
|
||||
- 即時に履行されないオファーはレジャーデータの[Offerオブジェクト](offer.html)になります。その後のオファーとPaymentにより、レジャーのOfferオブジェクトは消費されます。
|
||||
- [複数通貨間の支払い](cross-currency-payments.html)はオファーを消費して流動性を提供します。
|
||||
|
||||
|
||||
## オファーのライフサイクル
|
||||
|
||||
OfferCreateトランザクションの処理時に、このトランザクションは一致するオファーまたはクロスオファーを可能な限り自動的に消費します。（既存のオファーのレートが要求よりも良い場合には、オファーの作成者は`TakerGets`の全額よりも低い額を支払い、`TakerPays`を全額を受領できます。）それにより`TakerPays`の額を完全に満たせない場合、オファーはレジャーのOfferオブジェクトになります。（[OfferCreateフラグ](offercreate.html#offercreateフラグ)を使用してこの動作を変更できます。）
|
||||
|
||||
既存のオファーに対応する追加のOfferCreateトランザクション、またはオファーを使用してペイメントパスを接続する[Paymentトランザクション][]のいずれかにより、レジャー上のオファーは履行されます。オファーの部分的な履行と、部分的な資金化が可能です。1つのトランザクションで、レジャーのオファーを最大850件まで消費できます。（この数を超えるとメタデータが大きくなり過ぎて、[`tecOVERSIZE`](tec-codes.html)となります。）
|
||||
|
||||
オファーの`TakerGets`パラメーターで指定された通貨をいくらかでも（ゼロ以外のプラスの額）保有している限り、オファーを作成できます。オファーは、`TakerPays`の額が満たされるまで、`TakerGets`の額を上限として保有している通貨を売却します。オファーによって誰かに負債が発生することはありません。
|
||||
|
||||
レジャーにすでに記録されているオファーにクロスするオファーを出した場合、関連する額に関係なく古いオファーは自動的に取り消されます。
|
||||
|
||||
次の場合には、オファーは一時的または永久に _資金化されない_ 可能性があります。
|
||||
|
||||
* 作成者に`TakerGets`の通貨がない場合。
|
||||
* 作成者がその通貨を取得すると、オファーに資金が再び供給されます。
|
||||
* オファーに資金を供給するために必要な通貨が[凍結されたトラストライン](freezes.html)で保有されている場合。
|
||||
* トラストラインの凍結が解除されると、オファーに資金が再び供給されます。
|
||||
* オファーに必要な新しいトラストラインの準備金として十分な額のXRPを作成者が保有していない場合。（[オファーとトラスト](#オファーとトラスト)を参照してください。）
|
||||
* 作成者がXRPをさらに取得するか、または必要準備金が減額されると、オファーに資金が再び供給されます。
|
||||
* オファーに指定されている有効期限が最新の閉鎖済みレジャーの閉鎖時刻よりも前である場合。（[オファーの有効期限](#オファーの有効期限)を参照してください。）
|
||||
|
||||
資金化されないオファーはレジャーに無期限で残ることがありますが、特に影響はありません。次の方法でのみ、オファーはレジャーから*完全に*削除されます。
|
||||
|
||||
* Paymentトランザクションまたは対応するOfferCreateトランザクションにより全額が請求される。
|
||||
* OfferCancelトランザクションまたはOfferCreateトランザクションによりオファーが明示的に取り消される。
|
||||
* 同じアカウントからのOfferCreateトランザクションが以前のオファーにクロスする。（この場合、古いオファーが自動的に取り消されます。）
|
||||
* トランザクションの処理中にオファーへの資金が供給されていないことが判明する。一般的に、オファーがオーダーブックの先中で最も有利なレートであったことが原因です。
|
||||
* これには、オファーのいずれかの側が、`rippled`の精度でサポートされているよりも0に近いことが検出されるケースも含まれます。
|
||||
|
||||
### 資金化されていないオファーの追跡
|
||||
|
||||
すべてのオファーの資金化状況の追跡は、コンピューターにとって負荷の高い処理となることがあります。特に積極的に取引しているアドレスでは大量のオファーがオープンです。1つの残高が、さまざまな通貨を購入する多数のオファーの資金化の状況に影響することがあります。このため、`rippled`ではオファーの検出と削除を積極的に行なっていません。
|
||||
|
||||
クライアントアプリケーションでオファーの資金化の状況をローカルで追跡できます。このためには、最初に[book_offersメソッド][]を使用してオーダーブックを取得し、次にオファーの`taker_gets_funded`フィールドを調べます。次に`transactions`ストリームを[サブスクライブ](subscribe.html)し、トランザクションメタデータを監視してどのオファーが変更されるかを確認します。
|
||||
|
||||
|
||||
## オファーとトラスト
|
||||
|
||||
トラストラインの限度額（[TrustSet](trustset.html)を参照）はオファーに影響しません。つまり、オファーを使用して、イシュアーの信用できる最大精算額を上回る額を取得できます。
|
||||
|
||||
ただし、XRP以外の残高を保有するには、それらの残高を発行するアドレスへのトラストラインが必要です。オファーが受け入れられると、必要なトラストラインが自動的に作成され、その限度額が0に設定されます。[アカウントが保有する必要のある準備金はトラストラインによって増加する](reserves.html)ため、新しいトラストラインを必要とするオファーがある場合、そのトラストラインの準備金として十分なXRPをアドレスに保有する必要があります。
|
||||
|
||||
トラストラインはあなたが信用するイシュア―を示し、限度額の範囲内でそのイシュア―のイシュアンスを支払いとして受領します。オファーは特定通貨を取得するための明示的な指示であるため、これらの限度額を超えることができます。
|
||||
|
||||
|
||||
## オファーの優先度
|
||||
|
||||
既存のオファーは為替レート（「オファークオリティ」とも呼ばれます）によってグループにまとめられます。為替レートは、`TakerGets`と`TakerPays`の比率として計算されます。為替レートが高いオファーが優先的に処理されます。（つまり、オファーを受け入れる人は、支払われる通貨額に対して可能な限り多くを受領します。）同じ為替レートのオファーは、最も古いレジャーバージョンで出されたオファーに基づいて受け入れられます。
|
||||
|
||||
同じ為替レートのオファーが同じレジャーバージョンに記録されている場合、オファーの処理順序は[レジャーへトランザクションを適用する](https://github.com/ripple/rippled/blob/5425a90f160711e46b2c1f1c93d68e5941e4bfb6/src/ripple/app/consensus/LedgerConsensus.cpp#L1435-L1538 "Source: Applying transactions")ための[正規の順序](https://github.com/ripple/rippled/blob/release/src/ripple/app/misc/CanonicalTXSet.cpp "Source: Transaction ordering")によって決定します。この動作は確定的かつ効率的であり、操作することが困難であるように設計されています。
|
||||
|
||||
|
||||
## オファーの有効期限
|
||||
|
||||
トランザクションの伝搬と確定には時間がかかることがあるため、レジャーのタイムスタンプからオファーの有効性を判断します。オファーが有効期限切れとなるのは、有効期限が最新の検証済みレジャーよりも前の場合だけです。つまり、`Expiration`フィールドが指定されているオファーが「アクティブ」であると見なされるのは、ローカルクロックに関係なく、その有効期限が最新の検証済みレジャーのタイムスタンプよりも後である場合です。
|
||||
|
||||
閉鎖時刻が有効期限と同じかそれよりも後である完全な検証済みレジャーが作成されたら、`Expiration`が指定されているオファーの最終的な処理を即時に判断できます。
|
||||
|
||||
**注記:** レジャーを変更できるのは新しいトランザクションだけであることから、有効期限切れのオファーは、非アクティブになった後でもレジャーに残ることがあります。このオファーは資金化されていないと見なされ特に影響はありませんが、（[ledger_entry](ledger_entry.html)コマンドなどの）実行結果に、引き続き表示される可能性があります。後に、サーバーが処理中に有効期限切れのオファーを検出すると、このオファーは別のトランザクション（別のOfferCreateなど）の結果として最終的に削除されることがあります。
|
||||
|
||||
OfferCreateトランザクションが最初にレジャーに追加された時点で、このトランザクションに指定されている`Expiration`時刻をすでに経過していた場合は、トランザクションはオファーを実行しません。このようなトランザクションの結果コードは、[Checks Amendment][]:not_enabled:が有効であるかどうかによって異なります。Checks Amendmentが有効な場合、トランザクションの結果コードは`tecEXPIRED`です。それ以外の場合、トランザクションの結果コードは`tesSUCCESS`です。いずれの場合でも、このトランザクションには、[トランザクションコスト](transaction-cost.html)として支払われたXRPを消却する以外に影響はありません。
|
||||
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
23
content/concepts/decentralized-exchange/ticksize.ja.md
Normal file
23
content/concepts/decentralized-exchange/ticksize.ja.md
Normal file
@@ -0,0 +1,23 @@
|
||||
# ティックサイズ
|
||||
|
||||
_（[TickSize Amendment][]が必要です。）_
|
||||
|
||||
オファーがオーダーブックに対して発行されると、そのオファーに関係する通貨のイシュアーによって設定された`TickSize`の値に基づいて、為替レートが切り捨てられます。トレーダーがXRPと発行済み通貨を交換するオファーを出した場合は、その発行済み通貨のイシュアーからの`TickSize`が適用されます。トレーダーが2種類の発行済み通貨を交換するオファーを出した場合は、小さい方の`TickSize`の値（有効数字の桁数が少ない値）がこのオファーに適用されます。いずれの通貨にも`TickSize`が設定されていない場合、デフォルトが適用されます。
|
||||
|
||||
オーダーブックにオファーが発行されると、`TickSize` によりオファーの為替レートの _有効数字_ の桁数が切り捨てられます。イシュアーは[AccountSetトランザクション][]を使用して`TickSize`を`3`～`15`の整数に設定できます。為替レートは有効数字と指数で表されますが、`TickSize`は指数には影響しません。これにより、XRP Ledgerでは価値が大きく異なる資産（ハイパーインフレ通貨と希少通貨など）間の為替レートを表せます。イシュアーが設定する`TickSize`が小さいほど、トレーダーはより多くの増分をオファーして、既存のオファーよりも高い為替レートと見えるようにする必要があります。
|
||||
|
||||
`TickSize`は、オファーの即時に実行可能な部分には影響しません。（この理由から、`tfImmediateOrCancel`が指定されたOfferCreateトランザクションは`TickSize` の値の影響を受けません。）オファーを完全に実行できない場合、トランザクション処理エンジンは`TickSize`に基づいて為替レートを計算して切り捨てを行います。次にエンジンは、切り捨てた後の為替レートに一致するように、「重要性が低い」側からのオファーの残額を丸めます。デフォルトのOfferCreateトランザクション（「買い」オファー）の場合、`TakerPays`の額（購入額）が丸められます。`tfSell`フラグが有効な場合（「売り」オファー）`TakerGets`の額（売却額）が丸められます。
|
||||
|
||||
イシュアーが`TickSize`を有効化、無効化、または変更する場合、以前の設定で発行されたオファーはその影響を受けません。
|
||||
|
||||
## 参照項目
|
||||
|
||||
- [Dev Blog: Introducing the TickSize Amendment](https://ripple.com/dev-blog/ticksize-amendment-open-voting/#ticksize-amendment-overview)
|
||||
|
||||
- [AccountSetトランザクション][]
|
||||
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
70
content/concepts/introduction/intro-to-consensus.ja.md
Normal file
70
content/concepts/introduction/intro-to-consensus.ja.md
Normal file
@@ -0,0 +1,70 @@
|
||||
# コンセンサスについて
|
||||
|
||||
_コンセンサス_ は、分散型決済システムの最も重要な特性です。従来の中央集権型決済システムでは、権限のある1人の管理者が決済の方法とタイミングについて最終的な決定権を持ちます。分散型システムでは、その名が示すとおり、そのような管理者は存在しません。その代わりに、XRP Ledgerのような分散型システムでは、参加者は定められた一連のルールに従うことになっているため、同じ一連のイベントとその結果についていつでも合意することができます。この一連のルールは、 _コンセンサスプロトコル_ と呼ばれます。
|
||||
|
||||
|
||||
## コンセンサスプロトコルの特性
|
||||
|
||||
従来のデジタル資産と異なり、XRP Ledgerでは、コンセンサスプロトコルを使用します。このプロトコルは、XRP Ledger コンセンサスプロトコルと呼ばれ、次の重要な特性を持つように設計されています。
|
||||
|
||||
- XRP Ledgerを使用するユーザーは誰でも、最新の台帳や、どのような取引がどのような順番で発生したかについて同意することができます。
|
||||
- 中央のオペレーター無しに、有効な取引を処理することができます。また、障害が1か所に集中することもありません。
|
||||
- 一部の参加者が不適切に参加、退去、または行動した場合でも、取引の処理は続行します。
|
||||
- 多数の参加者がアクセスできない場合や、多数が不適切に行動している場合は、無効な取引を分離したり確認したりする代わりに、ネットワークは処理を停止します。
|
||||
- 取引の確認のために、リソースを無駄に使ったり取り合う必要もありません。この点は、他の一般的なブロックチェーンシステムとは異なります。
|
||||
|
||||
これらの特性は、次の3原則としてまとめられます。優先順位の高い順に示します。**正確さ、合意、処理の継続**
|
||||
|
||||
このプロトコルはまだ発展段階にあり、その限界と起こり得る障害についての知識もまだ蓄積中です。プロトコル自体に関する学術研究については、[コンセンサスリサーチ](consensus-research.html)を参照してください。
|
||||
|
||||
## 背景
|
||||
|
||||
コンセンサスプロトコルは、_二重支払いの問題_、つまり同じデジタルマネーを2回使用することを防ぐという課題に対する解決策です。この問題において最も困難なのは、取引を順序立てる点です。中央管理者がいない中で、同時に複数の相互排他的取引が送信されたときに、先に到着したのはどの取引なのかという紛争を解決するのは困難です。二重支払いの問題や、XRP Ledger コンセンサスプロトコルでこの問題を解決する方法、およびそれに伴うトレードオフと制限事項の詳細な分析については、[コンセンサスの原理とルール](consensus-principles-and-rules.html)を参照してください。
|
||||
|
||||
|
||||
## レジャー（台帳）履歴
|
||||
|
||||
XRP Ledgerは、「レジャーバージョン」、または略して「レジャー」と呼ばれるブロックで取引を処理します。レジャーの各バージョンには、次の3つの部分が含まれています。
|
||||
|
||||
- レジャーに保存されているすべての残高とオブジェクトの現在の状態。
|
||||
- このレジャーにつながる、以前のレジャーに適用された一連の取引。
|
||||
- レジャーインデックスや、その内容を一意に識別する[暗号化ハッシュ](https://en.wikipedia.org/wiki/Cryptographic_hash_function)、およびこのレジャーを構築するための基盤として使用された親レジャーに関する情報など、現行のレジャーバージョンに関するメタデータ。
|
||||
|
||||
[](img/anatomy-of-a-ledger-simplified.ja.png)
|
||||
<!--{# Diagram source: https://docs.google.com/presentation/d/1mg2jZQwgfLCIhOU8Mr5aOiYpIgbIgk3ymBoDb2hh7_s/ #}-->
|
||||
|
||||
レジャーの各バージョンには _レジャーインデックス_ としての番号が付けられており、インデックスが1つ前のレジャーバージョンを基に新たな情報を追加する形で作成されています。一番最初まで遡ると、レジャーインデックスが1の _ジェネシスレジャー_ と呼ばれる出発点に戻ります。[¹](#footnote-1)これにより、Bitcoinや他のブロックチェーン技術と同様に、すべての取引とその結果についての公開履歴が形成されます。多くのブロックチェーン技術とは異なり、XRP Ledgerの新しい「ブロック」には現在の状態がすべて含まれているため、現在起こっている内容を把握するために履歴全体を収集する必要はありません。[²](#footnote-2)
|
||||
|
||||
XRP Ledger コンセンサスプロトコルの主な役割は、前のレジャーに適用する一連の新しい取引に合意し、それらを明確に定義された順序で適用した上で、全員が同じ結果を得たことを確認することです。これが正常に行われると、レジャーバージョンは _検証済み_ 、および確定したとみなされます。続いて、次のレジャーバージョンが構築されます。
|
||||
|
||||
|
||||
## 信頼に基づく検証
|
||||
|
||||
XRP Ledgerのコンセンサスメカニズムは、小さな信頼が大きな効果を生み出すという基本的な原理に支えられています。ネットワークの各参加者は、一連の _バリデータ_ （検証者）を選択します。バリデータは常に誠実に行動することが期待されるさまざまな当事者によって運営されており、[コンセンサスにアクティブに参加するように特別に設定されたサーバー](run-a-rippled-validator.html)上に存在します。さらに重要なことは、選択された一連のバリデータが互いに共謀して同じ方法を使ってルールを破ることはないということです。この一連バリデータのリストは、_ユニークノードリスト_（UNL）とも呼ばれます。
|
||||
|
||||
ネットワークが更新する中で、各サーバーは信頼できるバリデータ[³](#footnote-3)をモニターします。十分な数のバリデータが、一連の取引の発生を確認し、特定のレジャーにその結果が反映されたことに同意した場合、サーバーによってコンセンサスが宣言されます。バリデータ間で同意が得られない場合、バリデータは信頼する他のバリデータとの間での意見の一致に向けて提案を修正します。このプロセスは、コンセンサスに達するまで何度か繰り返されます。
|
||||
|
||||
[](img/consensus-rounds.ja.png)
|
||||
|
||||
常に正しく行動しないバリデータが一部存在しても問題ありません。信頼できるバリデータのうち、正しく行動しないバリデータの割合が20%未満である場合は、制限なくコンセンサスは継続します。また、無効な取引を確認するには、信頼できるバリデータの80%以上が合意する必要があります。信頼できるバリデータのうち、正しく行動しないバリデータの割合が20%以上80%未満である場合、ネットワークは停止します。
|
||||
|
||||
XRP Ledger コンセンサスプロトコルで、さまざまな課題や攻撃、失敗の事例にどのように対応するかについての詳細な説明については、[攻撃と失敗モードに対するコンセンサスの保護](consensus-protections.html)を参照してください。
|
||||
|
||||
|
||||
## 関連項目
|
||||
|
||||
- XRP Ledger コンセンサスプロトコルの仕組みの詳細に関する記事は、[コンセンサスネットワークの概念](consensus-network.html)を参照してください。
|
||||
- 独自のバリデータを実行する手順については、[バリデータとしての`rippled`の実行](run-rippled-as-a-validator.html)を参照してください。
|
||||
- XRP Ledgerの分散化に関するRippleの目標および計画については、[分散化戦略についてのアップデート (Ripple Dev Blog)](https://ripple.com/dev-blog/decentralization-strategy-update/)を参照してください。
|
||||
|
||||
<!--{# TODO: Replace the Decent Strategy Update w/ a newer article when we have one #}-->
|
||||
|
||||
----
|
||||
|
||||
## 脚注
|
||||
|
||||
1. <a id="footnote-1"></a>XRP Ledgerの運用開始当初に起きた事故により、[1～32569番目までのレジャーが失われました](https://forum.ripple.com/viewtopic.php?f=2&t=3613)。（この損失はレジャー履歴の第1週目に発生しています。）このため、現存する一番最初のレジャーは番号32570のレジャーです。XRP Ledgerの状態はすべてのレジャーバージョンに記録されるため、履歴がなくても継続することができます。新しいテストネットワークでは、レジャーインデックス1から始まります。
|
||||
|
||||
2. <a id="footnote-2"></a>Bitcoinでは、現在の状態は「UTXO」（Unspent Transaction Outputの略）と呼ばれることもあります。XRP Ledgerとは異なり、BitcoinサーバーではすべてのUTXOを把握し、新しい取引を処理できるように、トランザクション（取引）履歴全体をダウンロードする必要があります。2018年現在、Bitcoinの新しいサーバーでこれを行う必要がないように、最新のUTXOのサマリーを定期的に提供するようコンセンサスメカニズムを修正する提案がいくつかあります。EthereumはXRP Ledgerと類似したアプローチを使用しており、各ブロックには、 _状態ルート_ と呼ばれる現在の状態のサマリーがありますが、Ethereumは巨大な状態データを蓄積しているため同期するにはXRP Ledgerよりもより多くの時間を要します。
|
||||
|
||||
3. <a id="footnote-3"></a>信頼できるバリデータをモニターするにあたり、サーバーが直接それに接続する必要はありません。XRP Ledgerのピアツーピアネットワークでは、サーバーが公開鍵によって互いを識別し、他のサーバーからのデジタル署名付きメッセージを中継する _ゴシッププロトコル_ によってモニターします。
|
||||
108
content/concepts/introduction/technical-faq.ja.md
Normal file
108
content/concepts/introduction/technical-faq.ja.md
Normal file
@@ -0,0 +1,108 @@
|
||||
# 技術に関するよくある質問
|
||||
|
||||
## バリデータ（検証者）とユニークノードリスト
|
||||
|
||||
<!--#{ using h4s for questions to keep them out of the right side nav (too cluttered when they display) and to provide appropriate text size for questions. #}-->
|
||||
#### トランザクション（取引）のバリデータはどのようなサービスを提供するのですか?
|
||||
|
||||
バリデータは、トランザクションがプロトコル要件を満たしていて、結果として「有効」であるかどうかを判断します。バリデータが提供する独自の機能は、順序付けされた単位にトランザクションをグループ化し、二重支払いを防ぐことを目的としてその順序に同意することです。
|
||||
|
||||
コンセンサスプロセスの詳細については、[Consensus](consensus.html)と[Ripple Labs Tech Talk: Understanding Consensus](https://ripple.com/insights/ripple-labs-tech-talk-consensus-within-the-ripple-protocol/)を参照してください。
|
||||
|
||||
|
||||
#### バリデータの実行にはいくらかかりますか?
|
||||
|
||||
バリデータを実行するのに手数料やXRPは必要ありません。メールサーバーを稼働するための電気代相当です。
|
||||
|
||||
|
||||
#### ユニークノードリスト（UNL）とは何ですか?
|
||||
|
||||
特定の参加者が、互いに共謀して自身をだますような企てを行わないものとして信頼するトランザクションバリデータから構成されるリストです。
|
||||
|
||||
|
||||
#### どのUNLを選択すればよいですか?
|
||||
|
||||
誰でもバリデータになりえるため、信頼できるセットを選択する責任はネットワーク参加者側にあります。現在、Rippleではデフォルトかつ推奨するリストを提供しています。これは、Rippleおよび第三者によって運用されているバリデータの履歴を見て、弊社が更新しているものです。最終的には、バリデータの品質に関して公表されているデータに基づいてネットワークの参加者自身が独自にリストを選択できるようになることで、Ripple自体がこのプロセスから身を引くようになると意図しています。
|
||||
|
||||
|
||||
#### RippleがそのUNLの採用を推奨しているなら、それは集中型システムを形成することにならないのですか?
|
||||
|
||||
いいえ。XRP Ledgerネットワークはオプトイン方式です。各参加者は直接的または間接的に自身のUNLを選択することができます。万が一、Rippleが活動を停止したり、Rippleが悪意を持って行動したりした場合、参加者は自身のUNLを変更してXRP Ledgerを引き続き使用することができます。
|
||||
|
||||
|
||||
#### Rippleによって運用されないバリデータにとってインセンティブとなるものは何ですか?
|
||||
|
||||
XRP Ledgerが広まり、銀行間決済に広く使用されると、参加者にとってネットワークの信頼性と安定性を保証するというインセンティブがあります。このような場合、金融機関はネットワークに参加するために`rippled`サーバーを運用します。サーバーの運用開始後、バリデータを運用するための追加のコストと労力は基本的にかかりません。ソフトウェアスイッチをオフからオンに切り替えるだけです。XRP Ledgerの進化を決定するのはバリデータであるため、バリデータを運用することの主なインセンティブは、ネットワークの安定した運用と賢明な進化を維持し保護することです。
|
||||
|
||||
|
||||
#### 金融機関は、特定の制度上の基準や要件を満たすのに役立つトランザクションバリデータを設定できますか?
|
||||
|
||||
いいえ。トランザクション選択のためにカスタマイズされたバリデータポリシーを金融機関が設定することはできません。バリデータは既存のプロトコルに従う、従わないのいずれかを選択します。ソフトウェアは、プロトコルルールに従わない場合は機能しません。そのため、金融機関が社内の専門知識なしにカスタム実装を求めることはお勧めできません。
|
||||
|
||||
|
||||
#### ネットワーク内の20%を超えるノードが過半数と一致しない場合はどうなりますか? レジャー（台帳）の最終バージョンはどのように選択されますか?
|
||||
|
||||
コンセンサスを目的に新しく作られたUNLリストで継続するために、ネットワークが一時的に停止して再構成される場合があります。この一時的な処理の遅れは、むしろ二重支出のリスクを回避します。
|
||||
|
||||
レジャーの正式な最終バージョンを決定する過程で、一時的な内部バージョンが複数存在する可能性があります。分散型システムでは、すべてのノードが同じ順序でトランザクションを受け取るわけではないため、そのような内部バージョンが発生します。従来のBitcoinにおける類似の振る舞いとしては、2つのブロックがほぼ同時にマイニングされたために2つのサーバーがそれぞれ異なる最長チェーンを参照してしまう状況があります。
|
||||
|
||||
しかし、正式なレジャーバージョンは常に1つしかありません。他のバージョンは無関係で、何の影響も与えません。
|
||||
|
||||
|
||||
#### XRP Ledgerでは正式なバリデータのオンボーディングプロセスを使用していますか?
|
||||
|
||||
いいえ。XRP Ledgerは、中央権限のないシステムであるため、正式なバリデータのオンボーディングプロセスのようなものは存在しません。代わりに、Rippleでは推奨事項とベストプラクティスを提供しています。
|
||||
|
||||
|
||||
## XRPの役割
|
||||
|
||||
|
||||
#### RippleはなぜXRPを多く保有しているのですか?
|
||||
|
||||
RippleはXRPを保有することで、XRP Ledgerを可能な限り有用なものにするインセンティブを持つことになります。XRPは、Ledgerのネイティブ資産として存在し、スパム対策や、ユーザーにとって有益な場合にブリッジ通貨として使われます。それ以外の場合、トランザクションでXRPを使用するかどうかは完全にユーザーの自由です。
|
||||
|
||||
|
||||
#### XRP Ledgerでは大量のトランザクションが行われている場合にどう対応しますか?
|
||||
|
||||
XRP Ledgerは、スパム対策として、需要に基づいてトランザクションコストを動的に設定するように設計されています。潜在的なXRPの操作による影響は、時価総額とトランザクション量の増加に伴うネットワークサイズの拡大によって最小限に抑えられます。
|
||||
|
||||
|
||||
#### マネーロンダリングや疑わしい経済活動に対して、Rippleではどのような標準操作手順が実施されていますか?
|
||||
|
||||
Rippleは、XRP Ledgerネットワーク全体でAML(Anti-Money Laundering)フラグを監視および報告するとともに、必要に応じてFinCEN(Financial Crimes Enforcement Network )に疑わしい活動を報告することをコミットしています。
|
||||
|
||||
|
||||
## セキュリティー上の懸念
|
||||
|
||||
|
||||
#### サードパーティーにより提供されたコードをマスターコードベースに受け入れる前に、Rippleではどのような確認プロセスを行っていますか?
|
||||
|
||||
コード提供プロセスは、開発者がRippleの`rippled`リポジトリーに対してプルリクエストを出すことから始まります。このプルリクエストがあると、自動化された単体テストと統合テスト、およびそのプルリクエストによって変更されるコードについて専門知識を持つ開発者によりコードレビューが行われます。
|
||||
|
||||
プルリクエストが自動テストに合格し、レビュー担当者から承認されると、[リポジトリの信頼できる保守担当者](https://opensource.guide/best-practices/)によって、次のベータ版に含められるようにステージングされます。
|
||||
|
||||
#### RippleはXRP LedgerまたはXRP Ledgerネットワークを所有または管理していますか?
|
||||
|
||||
いいえ、RippleはXRP LedgerとXRP Ledgerネットワークを所有も管理もしていません。
|
||||
|
||||
Rippleは、コアとなるXRP Ledgerサーバー（[`rippled`](https://github.com/ripple/rippled)）のリファレンス実装を公開し、オープンソースコードベースに貢献しているエンジニアチームを雇用しています。Rippleはまた、利用可能なソフトウェアのプリコンパイル済みバイナリーパッケージも定期的に発行しています。必要に応じて、誰でも自由に[ソースからソフトウェアをダウンロードしてコンパイル](install-rippled.html)できます。
|
||||
|
||||
XRP Ledgerと通信するためにRippleのXRP Ledgerソフトウェアを使用する必要はありません。 `rippled` はオープンソースソフトウェアであり、[ISCライセンス](https://github.com/ripple/rippled/blob/develop/LICENSE)の条件に従う限り、誰でも使用、拡張、および変更できます。ISCライセンスは、ソフトウェアの拡張方法と適応方法を厳密に制限する他のオープンソースライセンスと比較して非常に柔軟です。
|
||||
|
||||
#### Rippleでは、ソフトウェアを安全にダウンロードする方法を提供していますか?
|
||||
|
||||
`rippled` ソースコードは<https://github.com/ripple/rippled>から入手できます。ここでは、`master`、`release`、および`develop`の各ブランチのヒントに、`rippled`開発者が署名したバージョン設定コミットが常に含まれています。XRP Ledgerは、CentOS、RedHat Enterprise Linux、Fedora、およびUbuntu用のビルド済みRPMパッケージも提供します。これらのパッケージは不正開封防止が施されており、その真正性を確認できるようにRippleによってデジタル署名されています。最後に、リリースノートは安全なWebサイトで公開されており、リポジトリーのコミットIDと公開されているRPMパッケージのmd5sumが含まれています。
|
||||
|
||||
|
||||
#### Rippleは検証用のコードベースとユーザーソフトウェア用のコードベースを区別していますか?
|
||||
|
||||
はい。ripple-libを含むXRP Ledger用のクライアントソフトウェアには、`rippled`（検証）とは異なるコードベースおよびリポジトリーがあります。
|
||||
|
||||
|
||||
## 関連項目
|
||||
|
||||
- [`rippled` コードベース](https://github.com/ripple/rippled)
|
||||
- ユーザーソフトウェアのコードベース
|
||||
- [ripple-lib](https://github.com/ripple/ripple-lib)
|
||||
- [ripplecharts-frontend](https://github.com/ripple/ripplecharts-frontend)
|
||||
- [Ripple GitHub Organization](https://github.com/ripple/)
|
||||
99
content/concepts/introduction/xrp-ledger-overview.ja.md
Normal file
99
content/concepts/introduction/xrp-ledger-overview.ja.md
Normal file
@@ -0,0 +1,99 @@
|
||||
# XRP Ledgerの概要
|
||||
|
||||
**XRP Ledger**は、ピアツーピア・サーバーのネットワーク機能を備えた分散型の暗号台帳です。XRP Ledgerは**XRP**の土台となるものであり、世界中で使用されている様々な通貨の橋渡しをするために設計されたデジタル資産です。RippleはXRP Ledgerの開発を主導し、_「価値のインターネット」_（情報が移動するようにお金が移動する世界）の実現に向けて鍵となる役割を果たすと期待されるXRPを推進しています。
|
||||
|
||||
## 決済のためのデジタル資産
|
||||
|
||||
XRPはXRP Ledger固有のデジタル資産です。暗号鍵を持ち、インターネットに接続できる人は誰でも、XRPを受け取り、保持し、任意の人に送ることができます。XRPは他の通貨での取引をも容易にできる魅力的なブリッジ通貨として開発されました。XRPには次のような多くの特性があり、これにより他の多くのユースケースでも魅力的な資産となっています。
|
||||
|
||||
- **[耐検閲性のある取引処理][]:** どの特定の個人もXRP取引の成功・不成功を勝手に決定することはできませんし、一度完了した取引を組み戻すこともできません。ネットワークに参加するユーザーは、ネットワークを健全に保っている限り、XRPを数秒で送受信できます。
|
||||
- **[高速で効率的なConsensusアルゴリズム][]:** XRP LedgerのConsensusアルゴリズムは、最大1500件/秒のスループットで取引を処理し、4秒から5秒で完了します。これらの特性により、XRPは、他の上位デジタル資産の少なくとも10倍の優位性をもっています。
|
||||
- **[限定されたXRP供給量][]:** XRP Ledgerが開始された時、1000億XRPが発行され、今後さらにXRPが発行されることはありません。（各XRPは、小数第6位まで再分割でき、総計10万兆（10の17乗）_drop_（XRPの最小単位）となります。）取引に必要なコストを支払うために少額のXRPが毎回消却され、使用可能なXRPの供給量は時間とともにゆっくりと減少していきます。
|
||||
- **[責任あるソフトウェア管理][]:** Rippleでは、世界に通用する技術をもった常勤の開発チームが、XRP Ledgerの基礎となるソフトウェアを保守し、継続的に改良しています。Rippleは、技術の担い手として、さらに技術に対する支援者として、世界中の政府および金融機関と建設的な関係を築いています。
|
||||
- **[安全で適応性のある暗号技術][]:** XRP Ledgerは、ECDSA（Bitcoinが使用しているものと同じアルゴリズム）などの業界標準のデジタル署名システムを利用しています。またEd25519などの最新の効率的なアルゴリズムもサポートしています。XRP Ledgerのソフトウェアは拡張性に富み、最先端の暗号技術の進歩に合わせてアルゴリズムを追加したり消却にしたりすることが可能です。
|
||||
- **[スマートコントラクト用の最新機能][]:** Escrow、ChecksおよびPayment Channelなどの機能は、[Interledgerプロトコル](https://interledger.org/)を含む最新の金融アプリケーションをサポートしています。この拡張機能のツールボックスには、ネットワークの修正プロセスや、取引の不変性を担保するチェックを分けて行うなどの安全機能が備わっています。
|
||||
- **[台帳上の分散型取引所][]:** XRP自身を便利に使えるあらゆる機能に加えて、XRP Ledgerには、ユーザーが希望する任意の通貨で表示された債務を追跡し取引するための多機能な会計システムや、プロトコルに組み込まれた取引機能などがあります。XRP Ledgerは、通貨間の長い支払いパスや、複数通貨の一元的決済を確実に処理し、XRPを活用することで分散型ネットワークに存在する信頼のギャップを解消しています。
|
||||
|
||||
## 耐検閲性のある取引処理
|
||||
[耐検閲性のある取引処理]: #耐検閲性のある取引処理
|
||||
|
||||
XRPは、Bitcoinや他の暗号資産と同様に新しい通貨の一種です。
|
||||
|
||||
- これらの**分散型デジタル資産**はそれぞれのコンピューターシステム上に存在し、これを管理する中央管理者はいません。システムが十分に分散されている限り、取引を組み戻したり、残高を凍結したり、他のユーザーが分散型デジタル資産を使用することを阻止したりすることはできません。これらの資産はもともとデジタルであるため、離れた場所からもオンラインで使用できます。
|
||||
|
||||
これは物理的な通貨と中央集権型デジタル通貨の良い部分を併せ持っていることを意味します。2009年にBitcoinが発明されるまでは、すべての通貨は次の2つのカテゴリに分類できました。
|
||||
|
||||
- **物理的な硬貨および紙幣**。これは、中央の管理者を経由せずに、個人が決済するために使用できます。ただし、物理的なものであるためオンラインでは使用できず、長距離のビジネスで使うには時間がかかり不便です。
|
||||
- **中央集権型デジタル通貨**。これには、取引を承認する管理者が必要です。管理者には、取引の検閲や組み戻しの権限、また一部の個人がデジタル通貨を使用することを許可しない権限もあります。デジタル通貨の運営者は、誰かが利用規約に違反したことが判明した場合、その個人の通貨を凍結したり没収したりすることもできます。ただし、これらの通貨の残高はデジタルであるためオンラインで使用でき、離れた場所の取引にも便利です。
|
||||
|
||||
**注記:** XRP Ledgerのユーザーは、XRP Ledgerで発行されたXRP以外の通貨であれば凍結 _できます_ 。詳細は、[凍結についての資料](freezes.html)を参照してください。
|
||||
|
||||
信頼できるバリデータノードから構成されるXRP Ledgerのシステムでは、人手をほとんどかけることなく、他の分散型システムよりも優れた権限の分散が可能です。不特定多数の参加者間でのConsensusを完全に自動化しているシステムは、議決権の集中のリスクに晒されます。例えば、Bitcoinの採掘は、電気代が安い場所に偏って集中しています。Rippleは、様々な地域の異なる組織によって運営される別個のバリデータリストを管理しています。そのためXRP Ledgerは検閲などの外部の圧力に対してプルーフ・オブ・ワークによる採掘よりも高い耐性を持つことができます。推奨されるバリデータを分散させるためのRippleの対応策の詳細は、[分散化戦略についてのアップデート](https://ripple.com/dev-blog/decentralization-strategy-update/)を参照してください。
|
||||
|
||||
XRP Ledgerの検閲機能の詳細については、[取引検閲の検知](transaction-censorship-detection.html)を参照してください。
|
||||
|
||||
|
||||
## 高速で効率的なConsensusアルゴリズム
|
||||
[高速で効率的なConsensusアルゴリズム]: #高速で効率的なconsensusアルゴリズム
|
||||
|
||||
XRP Ledgerが多くの暗号資産と最も異なっている点は、BitcoinやEthereumなど他のほとんどのシステムが行う「採掘」の時間と労力を必要とせず、独自のConsensusアルゴリズムを使用していることです。「プルーフ・オブ・ワーク」または「プルーフ・オブ・ステーク」の代わりに、XRP LedgerのConsensusアルゴリズムでは、すべての参加者が重複する「信頼されるバリデータ」のリストを持ち、どの取引がどの順序で発生したかについて効率的に合意するシステムとなっています。2018年の初めの時点で、Bitcoinネットワークが取引ごとに使用する電力量は、米国の一世帯の住宅で1日に使用される量よりも多く、さらに取引の承認には何時間もかかっています。1つのXRP取引で使用される電力量はごく少量であり、承認には4秒から5秒しかかかりません。
|
||||
|
||||
さらに、XRP Ledgerのそれぞれの新しい「台帳バージョン」（「ブロック」と同義）には、すべての残高が完全かつ最新の状態で保持されているため、サーバーは、何時間もかけてすべての取引履歴をダウンロードして再処理する必要がなく、数分でネットワークと同期することができます。
|
||||
|
||||
XRP LedgerのConsensusアルゴリズムの動作方法の詳細は、[XRP Ledger Consensusプロセス](consensus.html)を参照してください。XRP LedgerがこのConsensusアルゴリズムを使用する理由の背景は、[Consensusの原理とルール](consensus-principles-and-rules.html)を参照してください。
|
||||
|
||||
|
||||
## 限定されたXRP供給量
|
||||
[限定されたXRP供給量]: #限定されたxrp供給量
|
||||
|
||||
戦争および政変と並んで、超インフレは通貨が消滅する主な原因の1つです。バリデータが分散しているため、XRPは政治的要因に対してはある程度の耐性があります。一方、超インフレに対しては、XRP Ledgerのルールにより簡潔なソリューションで対応しています。つまりXRPのトータル供給量の限定です。発行量を増やすメカニズムがそもそもないため、XRPが超インフレに悩まされる可能性は非常に低くなります。
|
||||
|
||||
市場に出回るXRPの供給量は、次のいくつかの要因によって変化 _します_ 。
|
||||
|
||||
- XRP Ledgerで取引を送信すると、毎回少額のXRPが消却されます。送信者は消却する額を選択できますが、予想される取引の処理作業とネットワークの混雑度に応じて一定の最低額が設定されています。ネットワークが混み合っている場合、より多くのXRPを消却するよう選択している取引は、取引キューの前に割り込むことができます。これはスパム防止策で、XRP Ledgerネットワークに対する[DDoS](https://en.wikipedia.org/wiki/Denial-of-service_attack)攻撃にかかるコストは極めて高額になります。詳細は、[取引コスト](transaction-cost.html)を参照してください。
|
||||
- XRP Ledgerの各アカウントは、少額のXRPを準備しておく必要があります。これもスパム防止策で、台帳データが必要以上に増えてしまうことを防ぎます。XRP Ledgerのバリデータは、実世界でのXRPの価値の変動に対応する目的で、準備金として必要なXRPの金額を変更するために投票決議を行うことができます。（この投票が前回発生したのは2013年の12月であり、このときは[必要な準備金が50 XRPから20 XRPに減少しました](https://ripple.com/insights/proposed-change-to-ripple-reserve-requirement-2/)。）必要な準備金が減少すると、以前は準備金によって使用できなくなっていた部分のXRPが再び使用可能になります。
|
||||
- Ripple（会社）は、大量のXRPをEscrowに保有しています。毎月の初めに、Rippleで使用するために10億XRPがEscrowから引き出されます。（RippleはXRPを使用してXRP Ledgerエコシステムの成長を促し、また一部のXRPを機関投資家に売却しています。Rippleはまた、取引所での取引総量のうちのわずかな比率に限定して、プログラムに従って取引所でXRPを売却しています。Rippleは[XRP市場レポート](https://ripple.com/insights/q1-2018-xrp-markets-report/)で四半期ごとに売上高を公開しています。）毎月の終わりに、Rippleが売却や譲渡をせずに残っているXRPがあればEscrowに戻し、54か月保管します。RippleのEscrowポリシーの詳細は、[Ripple社はXRPの供給の予測可能性向上のために55BnのXRPをエスクローに預託しました](https://ripple.com/insights/ripple-to-place-55-billion-xrp-in-escrow-to-ensure-certainty-into-total-xrp-supply/)を参照してください。Escrow機能の技術的詳細は、[Escrow](escrow.html)を参照してください。
|
||||
|
||||
|
||||
## 責任あるソフトウェア管理
|
||||
[責任あるソフトウェア管理]: #責任あるソフトウェア管理
|
||||
|
||||
ソフトウェアの水準は、そのソフトウェアを作成して管理する開発者によって決まります。Rippleは、XRP Ledgerソフトウェア、特にコアサーバーである`rippled`の保守および改良に専念する優秀な常勤エンジニアチームを雇用しています。[`rippled`のソースコード](https://github.com/ripple/rippled/)は、XRP Ledgerエコシステムの他の多くの部分と同様に、一般利用が可能なオープンソースライセンスを有するソフトウェアとして公開されています。Rippleのエンジニアは、次のようなソフトウェアエンジニアリングのベストプラクティスに従っています。
|
||||
|
||||
- 慎重で徹底的なコードレビュープロセス
|
||||
- 包括的なコードカバレッジと単体テスト
|
||||
- 潜在的な脆弱性およびメモリーリークの自動チェックの定期的な実行
|
||||
- 専門家組織による外部レビューヘの定期的な委託
|
||||
|
||||
巨額のXRPを長期にわたって保持する義務がある組織として、Rippleは、XRPが法に準拠して持続的かつ建設的な方法で広く使用されるために努力する強い自発的なインセンティブを持っています。「価値のインターネット」というRippleの理想と同じ目標を持つ企業に対して、Rippleは技術的なサポートを提供します。Rippleはまた、世界中の立法当局や規制当局と協力し、デジタル資産および関連ビジネスを管理する合理的な法律の実施に向けて誘導しています。
|
||||
|
||||
|
||||
## 安全で適応性のある暗号技術
|
||||
[安全で適応性のある暗号技術]: #安全で適応性のある暗号技術
|
||||
|
||||
暗号技術は分散システムにおいて最も重要な部分の1つであり、小さな技術的問題が一瞬にして世界中の悪意あるハッカーによる盗難につながる危険性を秘めています。XRP Ledgerは、取引の署名および検証のための業界標準の技術と、何年もの間、数千億USドルにも相当する価値を保護することに成功してきたアルゴリズムを使用しています。また、XRP Ledgerにはマルチ署名機能が備わっているため、バックアップとして多要素認証や複数のユーザー間で分割キーを使用できます。さらに暗号技術の飛躍的な進歩によって古いアルゴリズムが時代遅れになり、新しいアルゴリズムが導入される場合でも、ユーザーはそのままキーを使い続けることができます。
|
||||
|
||||
詳細は、[暗号鍵](cryptographic-keys.html)および[マルチ署名](multi-signing.html)を参照してください。
|
||||
|
||||
|
||||
## スマートコントラクト用の最新機能
|
||||
[スマートコントラクト用の最新機能]: #スマートコントラクト用の最新機能
|
||||
|
||||
XRP決済による単純な価値の移動に加えて、XRP Ledgerにはいくつかの拡張機能があります。「価値のインターネット」を標榜するアプリケーションの構築にこれらの機能を提供することにより、以前は知られていなかったニーズや実現困難であったニーズを満たすことができます。ネットワーク自体のなかで「スマートコントラクト」としてのアプリケーションを実行するのではなく、XRP Ledgerでは、コントラクトを処理するためのツールを提供しつつ、実行環境またはコンテナが適切であれば、すべての場所でアプリケーションを実行することができます。この「シンプルにする」というアプローチは、柔軟でスケーラブル、かつ強力です。
|
||||
|
||||
XRP Ledgerの拡張機能として次のものがあります。
|
||||
|
||||
- [Payment Channel](use-payment-channels.html)により、非同期の残高を署名の作成、検証とほぼ同時に変更することができます。
|
||||
- [Escrow](escrow.html)により、宣言した時間が経過するまで、または暗号条件が満たされるまで、XRPはロックされます。
|
||||
- [DepositAuth](depositauth.html)により、ユーザーは自分に対して送金できる相手か、送金できない相手かを決めることができます。
|
||||
- [分散型取引所](#台帳上の分散型取引所)により、ユーザーは台帳上で債務およびXRPを取引することができます。
|
||||
- [Invariant Checking](https://ripple.com/dev-blog/protecting-ledger-invariant-checking/)により、独立したレイヤーで取引実行時のバグから取引を保護することができます。
|
||||
- [Amendment](amendments.html)により、現行機能にスムーズにアップグレードすることができ、移行に際してエコシステムに被害を及ぼしたり、不確定要素を発生させることなく、継続して技術を発展させることができます。
|
||||
|
||||
|
||||
## 台帳上の分散型取引所
|
||||
[台帳上の分散型取引所]: #台帳上の分散型取引所
|
||||
|
||||
XRP Ledgerを他の暗号資産ネットワークとは異なるものにしている最も大きな特徴は、XRP Ledger上に完全な取引機能が含まれている点です。このシステム内で、事業者（通常は「ゲートウェイ」と言います）は希望の通貨を顧客に自由に発行でき、その顧客はその特定ゲートウェイによってXRPに発行された通貨や他のゲートウェイによって発行された通貨を自由に取引できます。このようにXRP Ledgerでは、取引注文によって流動性を確保しつつ、複数通貨間の一元的な取引を実行することができます。
|
||||
|
||||
分散型取引所がどのように機能するかの詳細は、[分散型取引所](decentralized-exchange.html)を参照してください。ゲートウェイビジネスモデルの詳細は、[Become an XRP Ledger Gateway](become-an-xrp-ledger-gateway.html)を参照してください。
|
||||
15
content/concepts/introduction/xrp.ja.md
Normal file
15
content/concepts/introduction/xrp.ja.md
Normal file
@@ -0,0 +1,15 @@
|
||||
# XRP
|
||||
|
||||
**XRP**は、XRP Ledgerのネイティブ暗号資産です。XRP Ledgerのすべての[アカウント](accounts.html)間で相互にXRPを送金できます。アカウントは、最小限度額のXRPを[準備金](reserves.html)として保有する必要があります。XRP Ledgerアドレス間にてXRPの直接送金が可能で、ゲートウェイや流動性プロバイダーを必要としません。このため、XRPは便利なブリッジ通貨となりました。
|
||||
|
||||
XRP Ledgerの高度機能の一部（[Escrow](escrow.html)や[Payment Channel](use-payment-channels.html)など）は、XRPでのみ使えます。オーダーブックの[オートブリッジング](https://ripple.com/dev-blog/introducing-offer-autobridging/)は、XRPを使用して、2つの発行済み通貨のオーダーブックをXRPオーダーブックにマージして、合成された一つのオーダーブックを作成することで、分散型取引所の流動性を高めます。（たとえば、オートブリッジングによりUSD:XRPオーダーとXRP:EURオーダーがマッチングされ、USD:EURオーダーブックとなります。）
|
||||
|
||||
XRPはまた、ネットワークのスパムの防御対策としても機能します。すべてのXRP Ledgerアドレスには、XRP Ledger維持管理コストを支払うために少額のXRPが必要です。[トランザクションコスト](transaction-cost.html)と[準備金](reserves.html)は、XRP建ての中立的な手数料であり、どの当事者にも支払われません。レジャーのデータフォーマットで、XRPは[AccountRootオブジェクト](accountroot.html)に保管されます。
|
||||
|
||||
XRPのユースケース、メリット、最新情報についての詳細は、[XRPポータル](https://ripple.com/xrp-portal/)を参照してください。
|
||||
|
||||
## XRPの特性
|
||||
|
||||
一番最初のレジャーにて1000億XRPが発行され、これ以上新しいXRPは作成できません。XRPは、[トランザクションコスト](transaction-cost.html)によって消却されるか、またはキーの所有者がいないアドレスに送金すると失われることがあります。このため、XRPは本質的にはやや[デフレ通貨](https://en.wikipedia.org/wiki/Deflation)です。XRPがなくなることを心配する必要はありません。現時点の消却のペースでは、すべてのXRPが消却されるまでに約7万年かかります。またXRPの総供給量の変化に伴い、XRPの[価格と手数料が調整される可能性があります](fee-voting.html)。
|
||||
|
||||
技術的には、XRPは0.000001 XRPの単位まで正確に計算され、「Drop」と呼ばれます。[`rippled`API](rippled-api.html)では、XRPの量は常にXRPのdrop単位で指定する必要があります。たとえば1 XRPは`1000000` dropと表されます。詳細については、[通貨フォーマットのリファレンス](currency-formats.html)を参照してください。
|
||||
104
content/concepts/issued-currencies/authorized-trust-lines.ja.md
Normal file
104
content/concepts/issued-currencies/authorized-trust-lines.ja.md
Normal file
@@ -0,0 +1,104 @@
|
||||
# Authorized Trust Lines
|
||||
|
||||
XRP LedgerのAuthorized Trust Lines機能により、通貨イシュアーは自身の（XRP以外の）発行済み通貨を保有できるユーザーを制限できます。これにより、不明なXRP Ledgerアドレスは発行済み通貨を保有できなくなります。Authorized Trust Lines機能は発行済み通貨にのみ適用され、XRPには影響しません。
|
||||
|
||||
Authorized Trust Lines機能を使用するには、発行アドレスでRequireAuthフラグを有効にします。その後、発行アドレスは他のアドレスからのトラストラインを承認する[TrustSetトランザクション][]を送信できます。RequireAuthが有効であるときに発行アドレスから発行された資金を他のアドレスが保有できるのは、発行アドレスへのトラストラインが承認されている場合だけです。
|
||||
|
||||
トラストラインを承認するトランザクションには発行アドレスによる署名が必要ですが、これにより発行アドレスが危険にさらされる可能性が高くなります。RequireAuthが有効であるXRP Ledgerへの資金の送金プロセスは次のようになります。
|
||||
|
||||
1. 発行ゲートウェイがその発行アドレスを顧客に公開します。
|
||||
2. 顧客のXRP Ledgerアドレスからゲートウェイの発行アドレスへのトラストラインを作成するために顧客は[TrustSetトランザクション][]を送信します。これは、ゲートウェイが発行した特定通貨を特定の限度額まで保有することを顧客が望んでいることを意味します。
|
||||
3. ゲートウェイの発行アドレスは、顧客のトラストラインを承認するTrustSetトランザクションを送信します。
|
||||
|
||||
**ヒント:** 発行ゲートウェイは、顧客がトラストラインの作成を完了する前に、そのトラストラインを事前に承認できます（ステップ3）。これにより限度額がゼロのトラストラインが作成されます。顧客のTrustSetトランザクション（ステップ2）により、事前承認されたトラストラインに限度額が設定されます。_（[TrustSetAuth Amendment][]が必要です。）_
|
||||
|
||||
## RequireAuth設定
|
||||
|
||||
`RequireAuth`設定（[RippleAPI](rippleapi-reference.html)の`requireAuthorization`）をすることで、発行アドレスが当該通貨に関してその取引相手とのトラストラインを具体的に承認している場合を除き、すべての取引相手はアドレスから発行された残高を保有できなくなります。
|
||||
|
||||
用心として、発行ゲートウェイが[運用アドレスとスタンバイアドレス](issuing-and-operational-addresses.html)に対して`RequireAuth`を常に有効にし、これらのアドレスへのトラストラインを一切承認しないことが推奨されます。これにより、運用アドレスとスタンバイアドレスがXRP Ledgerで誤って通貨を発行することを防止できます。これは純粋な予防措置であり、発行アドレスにより作成された発行済み通貨の残高を、これらのアドレスが意図したとおりに送金することを阻止するものではありません。
|
||||
|
||||
Authorized Trust Lines機能を使用するには、イシュアーがその発行アドレスの`RequireAuth`も有効にする必要もあります。その後、発行アドレスは顧客からの[各トラストラインを承認する`TrustSet`トランザクションを送信する](#トラストラインの承認)必要があります。
|
||||
|
||||
**注意:** アカウントが`RequireAuth`を有効にできるのは、アカウントがトラストラインを所有しておらず、またXRP Ledgerにオファーがない場合に限られます。したがってXRP Ledgerで取引を開始する前に、この設定を使用するかどうかを決定しておく必要があります。
|
||||
|
||||
### RequireAuthの有効化
|
||||
|
||||
ローカルでホストされている`rippled`の[submitメソッド][]を使用して、RequireAuthフラグを有効にする[AccountSetトランザクション][]を送信する例を以下に示します。（このメソッドは、アドレスが発行アドレス、運用アドレス、スタンバイアドレスのいずれであっても同様に機能します。）
|
||||
|
||||
要求:
|
||||
|
||||
```
|
||||
POST http://localhost:5005/
|
||||
{
|
||||
"method": "submit",
|
||||
"params": [
|
||||
{
|
||||
"secret": "sn3nxiW7v8KXzPzAqzyHXbSSKNuN9",
|
||||
"tx_json": {
|
||||
"Account": "rUpy3eEg8rqjqfUoLeBnZkscbKbFsKXC3v",
|
||||
"Fee": "15000",
|
||||
"Flags": 0,
|
||||
"SetFlag": 2,
|
||||
"TransactionType": "AccountSet"
|
||||
}
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
{% include '_snippets/secret-key-warning.md' %}
|
||||
<!--{#_ #}-->
|
||||
|
||||
## アカウントのRequireAuthの有効化の確認
|
||||
|
||||
アカウントのRequireAuth設定の有効化の状態を確認するには、[account_infoメソッド][]を使用してアカウントを調べます。`Flags`フィールド（`result.account_data`オブジェクト）の値を、[AccountRootレジャーオブジェクトのビット単位フラグ](accountroot.html)と比較します。
|
||||
|
||||
`Flags`値と`lsfRequireAuth`フラグ値（0x00040000）のビット単位のANDの結果がゼロ以外の場合、アカウントではRequireAuthが有効になっています。結果がゼロの場合、アカウントではRequireAuthが無効になっています。
|
||||
|
||||
## トラストラインの承認
|
||||
|
||||
Authorized Trust Lines機能を使用している場合、他のアカウントからのトラストラインを最初に承認しなければ、これらの他のアカウントはあなたが発行する残高を保有できません。複数の通貨を発行する場合には、各通貨のトラストラインを個別に承認する必要があります。
|
||||
|
||||
トラストラインを承認するには、`LimitAmount`の`issuer`として信頼するユーザーを指定して、発行アドレスから[TrustSetトランザクション][]を送信します。`value`（信頼する額）を**0**のままにし、トランザクションの[tfSetfAuth](trustset.html#trustsetのフラグ)フラグを有効にします。
|
||||
|
||||
ローカルでホストされている`rippled`の[submitメソッド][]を使用して、顧客アドレス（rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn）が発行アドレス（rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW）からのUSDのイシュアンスを保有することを承認するTrustSetトランザクションを送信する例を以下に示します。
|
||||
|
||||
要求:
|
||||
|
||||
```
|
||||
POST http://localhost:8088/
|
||||
{
|
||||
"method": "submit",
|
||||
"params": [
|
||||
{
|
||||
"secret": "sn3nxiW7v8KXzPzAqzyHXbSSKNuN9",
|
||||
"tx_json": {
|
||||
"Account": "rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW",
|
||||
"Fee": "15000",
|
||||
"TransactionType": "TrustSet",
|
||||
"LimitAmount": {
|
||||
"currency": "USD",
|
||||
"issuer": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
|
||||
"value": 0
|
||||
},
|
||||
"Flags": 65536
|
||||
}
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
{% include '_snippets/secret-key-warning.md' %}
|
||||
<!--{#_ #}-->
|
||||
|
||||
## トラストラインの承認状況の確認
|
||||
|
||||
トラストラインの承認状況を確認するには、[account_linesメソッド][]を使用してトラストラインを調べます。要求の`account`フィールドに顧客のアドレスを指定し、`peer`フィールドにイシュアーのアドレスを指定します。
|
||||
|
||||
応答の`result.lines`配列で、必要とする通貨のトラストラインを表している`currency`フィールドを持つオブジェクトを見つけます。そのオブジェクトの`peer_authorized`フィールドに値`true`が設定されている場合は、イシュアー（要求の`peer`フィールドとして使用したアドレス）によりそのトラストラインが承認されています。
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
429
content/concepts/issued-currencies/freezes.ja.md
Normal file
429
content/concepts/issued-currencies/freezes.ja.md
Normal file
@@ -0,0 +1,429 @@
|
||||
# 発行済み通貨の凍結
|
||||
|
||||
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を有効にすることはできません。
|
||||
|
||||
|
||||
# 技術詳細
|
||||
|
||||
## Individual Freezeの有効化または無効化
|
||||
|
||||
### 使用する`rippled`
|
||||
|
||||
特定のトラストラインに対するIndividual Freezeを有効または無効にするには、`TrustSet`トランザクションを送信します。Freezeを有効にするには[`tfSetFreeze`フラグ](trustset.html#trustsetのフラグ)を使用し、無効にするには`tfClearFreeze`フラグを使用します。トランザクションのフィールドは次のとおりです。
|
||||
|
||||
| フィールド | 値 | 説明 |
|
||||
|----------------------|--------|-------------|
|
||||
| Account | 文字列 | Freezeを有効または無効にするXRP Ledgerアドレス。 |
|
||||
| TransactionType | 文字列 | `TrustSet` |
|
||||
| LimitAmount | オブジェクト | 凍結するトラストラインを定義するオブジェクト。 |
|
||||
| LimitAmount.currency | 文字列 | トラストラインの通貨（XRPは指定できません） |
|
||||
| LimitAmount.issuer | 文字列 | 凍結する取引相手のXRP Ledgerアドレス |
|
||||
| LimitAmount.value | 文字列 | この取引相手があなたに対して発行する通貨の数量として信頼できる数量を、引用符で囲んで指定します。金融機関の観点からは、通常これは`"0"`となります。 |
|
||||
| Flags | 数値 | 凍結を有効にするには、ビット`0x00100000`（tfSetFreeze）が有効な値を使用します。凍結を無効にするには、ビット`0x00200000`（tfClearFreeze）が有効な値を使用します。 |
|
||||
|
||||
`Fee`、`Sequence`、`LastLedgerSequence`パラメーターは[通常の方法で](transaction-basics.html#トランザクションへの署名とトランザクションの送信)設定します。
|
||||
|
||||
[WebSocket API](get-started-with-the-rippled-api.html#websocket-api)を使用してIndividual Freezeを有効にするTrustSetトランザクションを送信する例:
|
||||
|
||||
```
|
||||
{
|
||||
"id": 12,
|
||||
"command": "submit",
|
||||
"tx_json": {
|
||||
"TransactionType": "TrustSet",
|
||||
"Account": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
|
||||
"Fee": "12000",
|
||||
"Flags": 1048576,
|
||||
"LastLedgerSequence": 18103014,
|
||||
"LimitAmount": {
|
||||
"currency": "USD",
|
||||
"issuer": "rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW",
|
||||
"value": "110"
|
||||
},
|
||||
"Sequence": 340
|
||||
},
|
||||
"secret": "s████████████████████████████",
|
||||
"offline": false,
|
||||
"fee_mult_max": 1000
|
||||
}
|
||||
```
|
||||
|
||||
**注意:** シークレットキーを信頼できないサーバーに送信することや、安全ではないチャネル経由で送信することは避けてください。
|
||||
|
||||
|
||||
### RippleAPIを使用する
|
||||
|
||||
特定のトラストラインに対するIndividual Freezeを有効または無効にするには、[prepareTrustline](rippleapi-reference.html#preparetrustline)メソッドを使用して *Trustline* トランザクションを準備します。`trustline`パラメーターのフィールドは次のように設定してください:
|
||||
|
||||
| フィールド | 値 | 説明 |
|
||||
|--------------|--------|-------------|
|
||||
| currency | 文字列 | 凍結するトラストラインの[通貨](rippleapi-reference.html#currency)（XRPは指定できません） |
|
||||
| counterparty | 文字列 | 取引相手の[XRP Ledgerアドレス](rippleapi-reference.html#address) |
|
||||
| limit | 文字列 | この取引相手があなたに対して発行する通貨の数量として信頼できる数量を、引用符で囲んで指定します。金融機関の観点からは、通常これは`"0"`となります。 |
|
||||
| frozen | ブール値 | `true` このトラストラインのIndividual Freezeを有効にします。`false`Individual Freezeを無効にします。 |
|
||||
|
||||
残りの[トランザクションフロー](rippleapi-reference.html#transaction-flow)は他のトランザクションと同じです。
|
||||
|
||||
トラストラインのIndividual Freezeを有効にするJavaScript（ECMAScript 6）コードの例:
|
||||
|
||||
```js
|
||||
{% include '_code-samples/freeze/set-individual-freeze.js' %}
|
||||
```
|
||||
|
||||
|
||||
## Global Freezeの有効化または無効化
|
||||
|
||||
### 使用する`rippled`
|
||||
|
||||
アドレスに対してGlobal Freezeを有効にするには、`SetFlag`フィールドに[asfGlobalFreezeフラグ値](accountset.html#accountsetのフラグ)を指定した`AccountSet`トランザクションを送信します。Global Freezeを無効にするには、`ClearFlag`フィールドにasfGlobalFreezeフラグ値を指定します。
|
||||
|
||||
[WebSocket API](get-started-with-the-rippled-api.html#websocket-api)を使用してGlobal Freezeを有効にするAccountSetトランザクションを送信する例:
|
||||
|
||||
```
|
||||
{
|
||||
"id": 12,
|
||||
"command": "submit",
|
||||
"tx_json": {
|
||||
"TransactionType": "AccountSet",
|
||||
"Account": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
|
||||
"Fee": "12000",
|
||||
"Flags": 0,
|
||||
"SetFlag": 7,
|
||||
"LastLedgerSequence": 18122753,
|
||||
"Sequence": 349
|
||||
},
|
||||
"secret": "s████████████████████████████",
|
||||
"offline": false,
|
||||
"fee_mult_max": 1000
|
||||
}
|
||||
```
|
||||
|
||||
**注意:** シークレットキーを信頼できないサーバーに送信することや、安全ではないチャネル経由で送信することは避けてください。
|
||||
|
||||
|
||||
### RippleAPIを使用する
|
||||
|
||||
アドレスに対してGlobal Freezeを有効または無効にするには、[prepareSettings](rippleapi-reference.html#preparesettings)メソッドを使用して**Settings**トランザクションを準備します。`settings`パラメーターは、次のように設定されているオブジェクトです:
|
||||
|
||||
| フィールド | 値 | 説明 |
|
||||
|--------------|--------|-------------|
|
||||
| globalFreeze | ブール値 | `true` このアドレスに対してGlobal Freezeを有効にします。`false`Global Freezeを無効にします。 |
|
||||
|
||||
残りの[トランザクションフロー](rippleapi-reference.html#transaction-flow)は他のトランザクションと同じです。
|
||||
|
||||
アドレスに対してGlobal Freezeを有効にするJavaScript（ECMAScript 6）コードの例:
|
||||
|
||||
```js
|
||||
{% include '_code-samples/freeze/set-global-freeze.js' %}
|
||||
```
|
||||
|
||||
|
||||
|
||||
## No Freezeの有効化
|
||||
|
||||
### 使用する`rippled`
|
||||
|
||||
アドレスに対してNo Freezeを有効にするには、`SetFlag`フィールドに[asfNoFreezeフラグ値](accountset.html#accountsetのフラグ)を指定した`AccountSet`トランザクションを送信します。このトランザクションをマスターキーで署名する必要があります。有効にしたNo Freezeを無効にすることはできません。
|
||||
|
||||
[WebSocket API](get-started-with-the-rippled-api.html#websocket-api)を使用してNo Freezeを有効にするAccountSetトランザクションを送信する例:
|
||||
|
||||
WebSocket要求:
|
||||
|
||||
```
|
||||
{
|
||||
"id": 12,
|
||||
"command": "submit",
|
||||
"tx_json": {
|
||||
"TransactionType": "AccountSet",
|
||||
"Account": "raKEEVSGnKSD9Zyvxu4z6Pqpm4ABH8FS6n",
|
||||
"Fee": "12000",
|
||||
"Flags": 0,
|
||||
"SetFlag": 6,
|
||||
"LastLedgerSequence": 18124917,
|
||||
"Sequence": 4
|
||||
},
|
||||
"secret": "s████████████████████████████",
|
||||
"offline": false,
|
||||
"fee_mult_max": 1000
|
||||
}
|
||||
```
|
||||
|
||||
**注意:** シークレットキーを信頼できないサーバーに送信することや、安全ではないチャネル経由で送信することは避けてください。
|
||||
|
||||
### RippleAPIを使用する
|
||||
|
||||
アドレスに対してNo Freezeを有効または無効にするには、[prepareSettings](rippleapi-reference.html#preparesettings)メソッドを使用して**Settings**トランザクションを準備します。有効にしたNo Freezeを無効にすることはできません。`settings`パラメーターは、次のように設定されているオブジェクトです:
|
||||
|
||||
| フィールド | 値 | 説明 |
|
||||
|----------|---------|-------------|
|
||||
| noFreeze | ブール値 | `true` |
|
||||
|
||||
このトランザクションをマスターキーで[署名](rippleapi-reference.html#sign)する必要があります。残りの[トランザクションフロー](rippleapi-reference.html#transaction-flow)は他のトランザクションと同じです。
|
||||
|
||||
アドレスに対してNo Freezeを有効にするJavaScript（ECMAScript 6）コードの例:
|
||||
|
||||
```js
|
||||
{% include '_code-samples/freeze/set-no-freeze.js' %}
|
||||
```
|
||||
|
||||
|
||||
## Individual Freezeの確認
|
||||
|
||||
### 使用する`rippled`
|
||||
|
||||
トラストラインでIndividual Freezeが有効になっているかどうかを確認するには、以下のパラメーターを持つ[account_linesメソッド][]を使用します。
|
||||
|
||||
| フィールド | 値 | 説明 |
|
||||
|----------|---------|-------------|
|
||||
| account | 文字列 | イシュアーのXRP Ledgerアドレス |
|
||||
| peer | 文字列 | 取引相手のXRP Ledgerアドレス |
|
||||
| ledger\_index | 文字列 | 最新の検証済み情報を取得するには`validated`を使用します。 |
|
||||
|
||||
応答には、発行アドレスと取引相手がリンクされている各通貨のトラストラインの配列が含まれています。各トラストラインオブジェクトで以下のフィールドを確認します:
|
||||
|
||||
| フィールド | 値 | 説明 |
|
||||
|--------------|---------|-------------|
|
||||
| freeze | ブール値 | （省略される場合があります）`true`: 発行アドレスがこのトラストラインを凍結した場合。省略されている場合は、`false`と同じです。 |
|
||||
| freeze\_peer | ブール値 | （省略される場合があります）`true`: 取引相手がこのトラストラインを凍結した場合。省略されている場合は、`false`と同じです。 |
|
||||
|
||||
Individual Freezeを確認するためのWebSocket要求の例:
|
||||
|
||||
```
|
||||
{
|
||||
"id": 15,
|
||||
"command": "account_lines",
|
||||
"account": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
|
||||
"ledger": "validated",
|
||||
"peer": "rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW"
|
||||
}
|
||||
```
|
||||
|
||||
WebSocket応答の例:
|
||||
|
||||
```
|
||||
{
|
||||
"id": 15,
|
||||
"status": "success",
|
||||
"type": "response",
|
||||
"result": {
|
||||
"account": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
|
||||
"lines": [
|
||||
{
|
||||
"account": "rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW",
|
||||
"balance": "10",
|
||||
"currency": "USD",
|
||||
"freeze": true,
|
||||
"limit": "110",
|
||||
"limit_peer": "0",
|
||||
"peer_authorized": true,
|
||||
"quality_in": 0,
|
||||
"quality_out": 0
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
`"freeze": true`フィールドは、 rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpnが、rsA2LpzuawewSBQXkiju3YQTMzW13pAAdWへのUSDトラストラインに対してIndividual Freezeを有効にしたことを示しています。`"freeze_peer": true`フィールドがない場合、取引相手はトラストラインを凍結 _していません_ 。
|
||||
|
||||
|
||||
### RippleAPIを使用する
|
||||
|
||||
トラストラインに対するIndividual Freezeが有効になっているかどうかを確認するには、以下のパラメーターを持つ[`getTrustlines`メソッド](rippleapi-reference.html#gettrustlines)を使用します。
|
||||
|
||||
| フィールド | 値 | 説明 |
|
||||
|---------------|---------|-------------|
|
||||
| address | 文字列 | イシュアーのXRP Ledgerアドレス |
|
||||
| options.counterparty | 文字列 | 取引相手のXRP Ledgerアドレス |
|
||||
|
||||
応答には、発行アドレスと取引相手がリンクされている各通貨のトラストラインの配列が含まれています。各トラストラインオブジェクトで以下のフィールドを確認します:
|
||||
|
||||
| フィールド | 値 | 説明 |
|
||||
|----------------------|---------|-------------|
|
||||
| specification.frozen | ブール値 | （省略される場合があります）`true`: 発行アドレスがトラストラインを凍結した場合。 |
|
||||
| counterparty.frozen | ブール値 | （省略される場合があります）`true`: 取引相手がトラストラインを凍結した場合。 |
|
||||
|
||||
トラストラインが凍結されているかどうかを確認するJavaScript（ECMAScript 6）コードの例:
|
||||
|
||||
```js
|
||||
{% include '_code-samples/freeze/check-individual-freeze.js' %}
|
||||
```
|
||||
|
||||
|
||||
## Global FreezeとNo Freezeの確認
|
||||
|
||||
### 使用する`rippled`
|
||||
|
||||
アドレスがGlobal FreezeとNo Freezeのいずれかまたは両方を有効にしているかどうかを確認するには、以下のパラメーターを持つ[account_infoメソッド][]を使用します。
|
||||
|
||||
| フィールド | 値 | 説明 |
|
||||
|----------|---------|-------------|
|
||||
| account | 文字列 | 発行アドレスのXRP Ledgerアドレス |
|
||||
| ledger\_index | 文字列 | 最新の検証済み情報を取得するには`validated`を使用します。 |
|
||||
|
||||
[ビット単位AND](https://en.wikipedia.org/wiki/Bitwise_operation#AND)演算子を使用して応答の`account_data.Flags`フィールドの値を確認します:
|
||||
|
||||
* `Flags` AND `0x00400000`（[lsfGlobalFreeze](accountroot.html#accountrootのフラグ)）が _ゼロ以外_ の場合: Global Freezeが有効です。
|
||||
* `Flags` AND `0x00200000`（[lsfNoFreeze](accountroot.html#accountrootのフラグ)）が _ゼロ以外_ の場合: No Freezeが有効です。
|
||||
|
||||
WebSocket要求の例:
|
||||
|
||||
```
|
||||
{
|
||||
"id": 1,
|
||||
"command": "account_info",
|
||||
"account": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
|
||||
"ledger_index": "validated"
|
||||
}
|
||||
```
|
||||
|
||||
WebSocket応答:
|
||||
|
||||
```
|
||||
{
|
||||
"id": 4,
|
||||
"status": "success",
|
||||
"type": "response",
|
||||
"result": {
|
||||
"account_data": {
|
||||
"Account": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
|
||||
"AccountTxnID": "41320138CA9837B34E82B3B3D6FB1E581D5DE2F0A67B3D62B5B8A8C9C8D970D0",
|
||||
"Balance": "100258663",
|
||||
"Domain": "6D64756F31332E636F6D",
|
||||
"EmailHash": "98B4375E1D753E5B91627516F6D70977",
|
||||
"Flags": 12582912,
|
||||
"LedgerEntryType": "AccountRoot",
|
||||
"MessageKey": "0000000000000000000000070000000300",
|
||||
"OwnerCount": 4,
|
||||
"PreviousTxnID": "41320138CA9837B34E82B3B3D6FB1E581D5DE2F0A67B3D62B5B8A8C9C8D970D0",
|
||||
"PreviousTxnLgrSeq": 18123095,
|
||||
"Sequence": 352,
|
||||
"TransferRate": 1004999999,
|
||||
"index": "13F1A95D7AAB7108D5CE7EEAF504B2894B8C674E6D68499076441C4837282BF8",
|
||||
"urlgravatar": "http://www.gravatar.com/avatar/98b4375e1d753e5b91627516f6d70977"
|
||||
},
|
||||
"ledger_hash": "A777B05A293A73E511669B8A4A45A298FF89AD9C9394430023008DB4A6E7FDD5",
|
||||
"ledger_index": 18123249,
|
||||
"validated": true
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
上記の例では`Flags`の値は12582912です。この場合、次のJavaScriptコードのように、lsfGlobalFreezeフラグとlsfDefaultRippleフラグが有効になっています。
|
||||
|
||||
```js
|
||||
var lsfGlobalFreeze = 0x00400000;
|
||||
var lsfNoFreeze = 0x00200000;
|
||||
|
||||
var currentFlags = 12582912;
|
||||
|
||||
console.log(currentFlags & lsfGlobalFreeze); //4194304
|
||||
//therefore, Global Freeze is enabled
|
||||
|
||||
console.log(currentFlags & lsfNoFreeze); //0
|
||||
//therefore, No Freeze is not enabled
|
||||
```
|
||||
|
||||
### RippleAPIを使用する
|
||||
|
||||
アドレスに対してGlobal FreezeとNo Freezeのいずれか、または両方が有効になっているかどうかを確認するには、以下のパラメーターを持つ[`getSettings`メソッド](rippleapi-reference.html#getsettings)を使用します。
|
||||
|
||||
| フィールド | 値 | 説明 |
|
||||
|---------------|---------|-------------|
|
||||
| address | 文字列 | 発行アドレスのXRP Ledgerアドレス |
|
||||
|
||||
応答オブジェクトの以下の値を確認します:
|
||||
|
||||
| フィールド | 値 | 説明 |
|
||||
|---------------|---------|-------------|
|
||||
| noFreeze | ブール値 | （省略される場合があります）`true`: No Freezeが有効な場合。 |
|
||||
| globalFreeze | ブール値 | （省略される場合があります）`true`: Global Freezeが有効な場合。 |
|
||||
|
||||
アドレスに対するGlobal FreezeまたはNo Freezeが有効になっているかどうかを確認するJavaScript（ECMAScript 6）コードの例:
|
||||
|
||||
```js
|
||||
{% include '_code-samples/freeze/check-global-freeze-no-freeze.js' %}
|
||||
```
|
||||
|
||||
# 関連項目
|
||||
|
||||
* [GB-2014-02新機能残高凍結](https://ripple.com/files/GB-2014-02.pdf)
|
||||
* [凍結コードの例](https://github.com/ripple/ripple-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' %}
|
||||
@@ -0,0 +1,27 @@
|
||||
# 発行済み通貨の概要
|
||||
|
||||
XRP Ledgerでは、XRP以外の通貨はすべて**発行済み通貨**とされます。このようなデジタル資産（「イシュアンス」または「IOU」とも呼ばれます）は、「トラストライン」と呼ばれるアドレス間の会計上の関係で管理されます。発行済み通貨は通常、負債とも資産とも見なされるため、トラストラインの残高は、見る視点によってマイナスにもプラスにもなります。どのアドレスも（XRP以外の）通貨を自由に発行できますが、他のアドレスが希望する保有量によってのみ制限されます。
|
||||
|
||||
発行済み通貨は、同一通貨コードを使用する複数のイシュアーと保有者を通じて「Rippling」されます。これが役立つ場合もありますが、予期しない結果や望ましくない結果が生じることもあります。トラストライン上で[NoRippleフラグ](rippling.html)を使用すれば、トラストラインを通じたRipplingを防ぐことができます。
|
||||
|
||||
XRP Ledgerの分散型取引所では、発行済み通貨対XRPの取引や、発行済み通貨間の取引を行えます。
|
||||
|
||||
一般的なモデルでは、発行済み通貨は、XRP Ledger外部で保有されている通貨またはその他の資産に結び付けられています。通貨のイシュアー（_ゲートウェイ_）は、XRP Ledger外部の通貨を、XRP Ledgerの発行済み通貨の同等の残高と交換するための入出金処理を行います。ゲートウェイの運用方法についての詳細は、[XRP Ledgerのゲートウェイになる](become-an-xrp-ledger-gateway.html)を参照してください。
|
||||
|
||||
XRP Ledgerの発行済み通貨は他の用途にも使えます。たとえば、固定量の通貨をセカンダリアドレスに発行し、イシュアーへキーを譲渡すれば、「イニシャルコインオファリング」（ICO）を作成できます。
|
||||
|
||||
**警告:** ICOは米国では[証券と見なされ、規制対象となる](https://www.sec.gov/oiea/investor-alerts-and-bulletins/ib_coinofferings)可能性があります。
|
||||
|
||||
金融サービスビジネスを始める前に、関連規制を調査されることを強くお勧めします。
|
||||
|
||||
## 発行済み通貨の特性
|
||||
|
||||
XRP Ledger内の発行済み通貨はすべてトラストラインに存在し、レジャーのデータでは[RippleStateオブジェクト](ripplestate.html)として表示されます。発行済み通貨を作成するには、発行アドレスは、対象となる通貨に対し非ゼロ制限のあるイシュアーへのトラストラインを持つアドレスに対し、[Paymentトランザクション][]を送信します。（発行済み通貨は、このようなトラストラインを通じてRipplingする方法でも作成できます。）発行済み通貨を消去するには、通貨をイシュアーに戻します。
|
||||
|
||||
通貨のイシュアーは、2名の当事者が発行済み通貨で取引をする際に差し引かれる[送金手数料](transfer-fees.html)のパーセンテージを定義できます。
|
||||
|
||||
アドレスは発行済み通貨を[凍結](freezes.html)することもでき、企業が当該地域の金融規制に準拠する際に有用です。この機能が不要で、通貨を凍結しない場合は、アドレスが有する個別のトラストラインを凍結する機能と、Global Freezeを取り消す機能を放棄できます。XRPは凍結できません。
|
||||
|
||||
発行済み通貨は、あらゆる種類の通貨または資産（額面価格が極めて低い、または高いものを含む）に相当するとされています。通貨コードの種類と発行済み通貨の表記の数値制限に関する技術的な詳細は、[通貨フォーマットのリファレンス](currency-formats.html)を参照してください。
|
||||
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
@@ -0,0 +1,52 @@
|
||||
# 発行アドレスと運用アドレス
|
||||
|
||||
{% include '_snippets/issuing-and-operational-addresses-intro.md' %}
|
||||
<!--{#_ #}-->
|
||||
|
||||
## 資金のライフサイクル
|
||||
|
||||
XRP LedgerのXRP以外の通貨の残高（イシュアンス）はすべて、2つのXRP Ledgerアドレス間の会計上の関係に関連付けられています。Rippleが推奨する役割の分割を金融機関が行うと、その金融機関に関連する資金の流れは循環する傾向にあります。
|
||||
|
||||
[](img/funds_flow_diagram.ja.png)
|
||||
|
||||
発行アドレスはペイメントの送金時に、XRP Ledgerの会計上の関係に残高を作成します。ユーザーはXRP Ledger内のさまざまな会計上の関係と残高を交換できます。このため、XRP以外の残高を表す用語として _イシュアンス_ を使用します。イシュアンスの額は、発行アドレスの側から見ると債務を表すため、マイナスです。同じイシュアンスの額を発行アドレスの相手側から見ると、プラスになります。発行アドレスがペイメントを受領すると、送信されたイシュアンスが消去され、発行アドレスの債務が減少します。
|
||||
|
||||
イシュアンスは発行アドレスからスタンバイアドレスに送信されるか、または運用アドレスに直接送信されます。これらのイシュアンスはスタンバイアドレスから運用アドレスに送信されます。運用アドレスから他の取引相手（流動性プロバイダー、パートナー、その他の顧客など）にペイメントが送信されます。すべてのイシュアンスは発行アドレスとの会計上の関係に関連付けられているため、イシュアンスのペイメントと取引は、発行アドレスを「通じてRippling」されます。ペイメントが行われると、送金元と発行アドレスの会計上の関係において送金元の残高から支払額が引き落とされ、受取人と発行アドレスの会計上の関係において受取人の残高に支払額が入金されます。XRP Ledgerでは、オーダーブックや[資金のRipplingに対応する流動性プロバイダー](rippling.html)を通じて複数のイシュアーを結び付ける、より複雑な[パス](paths.html)もサポートされています。
|
||||
|
||||
## 発行アドレス
|
||||
|
||||
発行アドレスは、金庫に似ています。パートナーアドレス、顧客アドレス、運用アドレスは、発行アドレスとの間で会計上の関係（トラストライン）を作成しますが、発行アドレスから送信されるトランザクションは可能な限り少ない数に抑えられます。人間のオペレーターが定期的に、発行アドレスからトランザクションを作成、署名し、スタンバイアドレスまたは運用アドレスの残高を補充します。このようなトランザクションの署名に使用されるシークレットキーには、インターネットに接続されたどのコンピューターからもアクセスできないことが極めて重要です。
|
||||
|
||||
金庫とは異なり、発行アドレスは顧客またはパートナーからのペイメントを直接受領できます。XRP Ledgerのトランザクションはすべて公開されているため、自動システムは発行アドレスからのペイメントを監視する際にシークレットキーを必要としません。
|
||||
|
||||
### 発行アドレスの漏えい
|
||||
|
||||
不正使用者は金融機関の発行アドレスのシークレットキーを入手すると、際限なく新しいイシュアンスを作成し、分散型取引所でそのイシュアンスを取引できるようになります。これにより、金融機関が正式に取得したイシュアンスを識別して適切に清算することが難しくなります。金融機関の発行アドレスが乗っ取られた場合には、金融機関が新たに発行アドレスを作成する必要があり、また古い発行アドレスと会計上の関係を有するすべてのユーザーは新しいアドレスで、アカウントとの関係を新たに作成する必要があります。
|
||||
|
||||
### 複数の発行アドレス
|
||||
|
||||
金融機関はXRP Ledgerで1つの発行アドレスから複数の通貨を発行できます。ただし、いくつかの設定（[送金手数料](transfer-fees.html)のパーセンテージや[Global Freeze](freezes.html)の状況など）は、1つのアドレスから発行されるすべての通貨に同様に適用されます。金融機関が通貨ごとに設定を変えて柔軟に管理したい場合、金融機関は通貨ごとに異なる発行アドレスを使用する必要があります。
|
||||
|
||||
|
||||
## 運用アドレス
|
||||
|
||||
運用アドレスはレジに似ています。イシュアンスを顧客とパートナーに送信して、金融機関に代わってペイメントを行います。トランザクションに自動的に署名するには、運用アドレスのシークレットキーをインターネットに接続されたサーバーに保管する必要があります。（シークレットキーは暗号化して保管できますが、サーバーがトランザクションに署名する際にシークレットキーを暗号化解除する必要があります。）顧客とパートナーは、運用アドレスとの会計上の関係を作成すべきではありません。
|
||||
|
||||
各運用アドレスではイシュアンスの残高が限られています。運用アドレスの残高が少なくなると、金融機関は残高を補充するため、発行アドレスまたはスタンバイアドレスから送金します。
|
||||
|
||||
### 運用アドレスの漏えい
|
||||
|
||||
不正使用者が運用アドレスのシークレットキーを入手した場合に金融機関が失う可能性のある通貨額は、最大でも運用アドレスが保有している額までです。金融機関は、顧客やパートナーからのアクションなしに、新しい運用アドレスに切り替えることができます。
|
||||
|
||||
|
||||
## スタンバイアドレス
|
||||
|
||||
金融機関がリスクと利便性のバランスを保つためのもう1つの手段として、発行アドレスと運用アドレスの中間ステップとして「スタンバイアドレス」を利用することができます。金融機関はスタンバイアドレスという追加のXRP Ledgerアドレスに資金を供給できます。このアドレスのキーはオンライン上に保管されず、別の信頼できるユーザーに預けられています。
|
||||
|
||||
運用アドレスの資金が少なくなると、信頼できるユーザーがスタンバイアドレスを使用して運用アドレスの残高を補充できます。スタンバイアドレスの資金が少なくなると、金融機関は発行アドレスを使用して1回のトランザクションでスタンバイアドレスにより多くの額の通貨を送金できます。スタンバイアドレスは、送金された通貨を必要に応じてスタンバイアドレス間で分散できます。これにより発行アドレスのセキュリティが強化され、発行アドレスが実行する合計トランザクション数が減少し、1つの自動化システムの管理下に過剰な資金が残ることがなくなります。
|
||||
|
||||
運用アドレスと同様に、スタンバイアドレスは顧客やパートナーではなく発行アドレスとの間に会計上の関係を確立する必要があります。運用アドレスに適用される注意事項はすべてスタンバイアドレスにも適用されます。
|
||||
|
||||
### スタンバイアドレスの漏えい
|
||||
|
||||
スタンバイアドレスの漏えいが発生した場合、運用アドレスが漏えいした場合と同様の影響が及びます。不正使用者がスタンバイアドレスに保有される残高を盗むことが可能となり、金融機関は顧客やパートナーからのアクションなしに新しいスタンバイアドレスに切り替えることができます。
|
||||
99
content/concepts/issued-currencies/paths.ja.md
Normal file
99
content/concepts/issued-currencies/paths.ja.md
Normal file
@@ -0,0 +1,99 @@
|
||||
# パス
|
||||
|
||||
XRP Ledgerでは、送金元から受取人への支払いが中間ステップをどのように通過するかをパスによって定義します。パスはオーダーブックを通じて送金元と受取人を結び付けることで、複数通貨間の支払いを可能にします。また、負債を相殺するような複雑な決済もパスにより可能になります。
|
||||
|
||||
XRP Ledgerでは1つのPaymentトランザクションは複数のパスを使用でき、複数のソースの流動性を組み合わせて必要な額を送金することができます。そのため、トランザクションには使用可能なパスをまとめた _パスセット_ が含まれます。パスセットの中のパスでは開始時と終了時には同一通貨が使用される必要があります。
|
||||
|
||||
XRPは任意のアドレスに直接送金できるため、XRP間のトランザクションではパスは使用されません。
|
||||
|
||||
## パスのステップ
|
||||
|
||||
パスは、支払いの送金元と受取人を結ぶステップで構成されています。すべてのステップは次のいずれかを行います。
|
||||
|
||||
* 同一通貨の別のアドレスを通じたRippling
|
||||
* オーダーブックでの通貨の取引
|
||||
|
||||
別のアドレスを通じたRipplingは、負債を移動するプロセスです。一般的なケースでは、ある当事者に対するイシュアーの債務が削減され、別の当事者に対する債務が増加します。Ripplingは、トラストラインで結ばれているすべてのアドレスの間で発生させることができます。Ripplingのその他の例については、[NoRippleフラグについて](rippling.html)を参照してください。
|
||||
|
||||
通貨取引ステップの場合、パスステップにより変換先の通貨が指定されますが、オーダーブックにはオファーの状態は記録されません。レジャーが検証されるまではトランザクションの正規の順序は最終的ではないため、トランザクションの検証が完了するまでは、トランザクションがどのオファーをとるかは不明です。（各トランザクションは最終レジャーでの実行時に利用可能なオファーの中から最適なオファーをとるため、経験に基づいて推測することができます。） <!-- STYLE_OVERRIDE: will -->
|
||||
|
||||
いずれのタイプのステップでも、中間アドレスでは取得する価値と失う価値はほぼ同等です。トラストラインから同じ通貨の別のトラストラインへ残高がripplingするか、または以前に出されたオーダーに基づいて通貨が交換されます。場合によっては、[送金手数料](transfer-fees.html)、トラストラインクオリティ、または数値の丸め方が原因で、取得する価値と失われる価値が厳密に同等ではないことがあります。
|
||||
|
||||
[](img/paths-examples.ja.png)
|
||||
|
||||
|
||||
|
||||
# 技術詳細
|
||||
|
||||
## Pathfinding
|
||||
|
||||
`rippled` APIではPathfindingに使用できるメソッドが2つあります。[ripple_path_findメソッド][]は、1回限りのパスセットの検索を実行します。[path_findメソッド][]（WebSocketのみ）は、レジャーが閉鎖するか、またはサーバーがより適切なパスを検出するたびに、フォローアップ応答によって検索を拡大します。
|
||||
|
||||
署名時に`rippled`によりパスが自動的に入力されるようにするには、[signメソッド][]または[`submit`コマンド（署名と送信モード）](submit.html#署名と送信モード)への要求に`build_path`フィールドを指定します。ただし、トラブルを回避するために、署名前にPathfindingを個別に実行し、結果を確認することが推奨されます。
|
||||
|
||||
**注意:**`rippled`は可能な限り低コストのパスを検出するように設計されていますが、常にこのようなパスを検出できるわけではありません。信頼できない`rippled`インスタンスが改ざんされ、利益目的でこの動作が変更される可能性もあります。パスに沿った支払いの実行にかかる実際のコストは、送信時とトランザクション実行時で異なることがあります。
|
||||
|
||||
パスの検出は、新しいレジャーが検証されるたびに数秒ごとに変化する非常に難しい課題であるため、`rippled`は完全に最適なパスを検出するようには設計されていません。ただし、いくつかの有効なパスを検出し、特定額の送金コストを推定することができます。
|
||||
|
||||
|
||||
## 暗黙のステップ
|
||||
|
||||
規約として、パスのステップのいくつかは[Paymentトランザクションのフィールド](payment.html)により黙示的に示されます。これらのフィールドは、`Account`（送金元）、`Destination`（受取人）、`Amount`（通貨と納入額）、`SendMax`（通貨と送金額（指定されている場合））です。暗黙のステップは次のとおりです。
|
||||
|
||||
* パスの1番目のステップは、トランザクションの`Account`フィールドに定義されるとおり、トランザクションの送信者であると常に黙示されます。
|
||||
* トランザクションに、そのトランザクションの送信者ではない`issuer`が指定されている`SendMax`フィールドが含まれている場合、そのイシュアーはパスの2番目のパスとして黙示されます。
|
||||
* `SendMax`の`issuer`が送信側アドレス _である_ 場合、パスはその送信側アドレスから始まり、そのアドレスの特定の通貨のトラストラインのいずれかを使用できます。詳細は、[SendMaxおよびAmountの特殊な値](payment.html#sendmaxおよびamountで使用する特殊なイシュアーの値)を参照してください。
|
||||
* トランザクションの`Amount`フィールドに、トランザクションの`Destination`とは異なる`issuer` が指定されている場合、そのイシュアーはパスの最後から2番目のステップであると黙示されます。
|
||||
* 最後に、トランザクションの`Destination`フィールドに定義されるとおり、パスの最終ステップはトランザクションの受信者であることが常に黙示されます。
|
||||
|
||||
|
||||
## デフォルトパス
|
||||
|
||||
明示的に指定されたパスの他に、トランザクションは _デフォルトパス_ に沿って実行できます。デフォルトパスは、トランザクションの[暗黙のステップ](#暗黙のステップ)を接続する最も簡単な方法です。
|
||||
|
||||
デフォルトパスは次のいずれかになります。
|
||||
|
||||
* トランザクションで（イシュアーに関係なく）1種類の通貨のみが使用される場合、デフォルトパスでは支払いが、関連するアドレスを通じてRipplingされると想定されます。このパスは、これらのアドレスがトラストラインで接続されている場合にのみ機能します。
|
||||
* `SendMax`が省略されているか、または`SendMax`の`issuer`が送金元の場合、デフォルトパスが機能するためには送金元`Account`から宛先`Amount`の`issuer`へのトラストラインが必要です。
|
||||
* `SendMax`と`Amount`に異なる`issuer`値が指定されており、そのいずれも送金元または受取人ではない場合、これらの2つのイシュアー間のトラストラインでRipplingが必要となるため、デフォルトパスは有用ではない可能性があります。一般にイシュアーが互いに直接信頼し合うことはお勧めしません。
|
||||
* 複数通貨間のトランザクションの場合、デフォルトパスは支払元通貨（`SendMax`フィールドで指定）と宛先通貨（`Amount`フィールドで指定）の間でオーダーブックを使用します。
|
||||
|
||||
有効なすべてのデフォルトパスを次の図に示します。
|
||||
[](img/paths-default_paths.ja.png)
|
||||
|
||||
デフォルトパスを無効にするには[`tfNoDirectRipple`フラグ](payment.html#paymentのフラグ)を使用します。このケースでは、トランザクションに明示的に指定されたパスを使用してトランザクションを実行することだけが可能です。トレーダーはこのオプションを使用して裁定取引を実行できます。
|
||||
|
||||
|
||||
## パスの仕様
|
||||
|
||||
パスセットは配列です。パスセットの各要素は、個々の _パス_ を表す別の配列です。パスの各要素は、ステップを指定するオブジェクトです。ステップのフィールドを次に示します。
|
||||
|
||||
| フィールド | 値 | 説明 |
|
||||
|:-----------|:-----------------------|:---------------------------------------|
|
||||
| `account` | 文字列 - アドレス | _（省略可）_ 指定されている場合、このパスステップは指定されたアドレスを通じたRipplingを表します。このステップに`currency`フィールドまたは`issuer`フィールドが指定されている場合は、このフィールドを指定しないでください。 |
|
||||
| `currency` | 文字列 - 通貨コード | _（省略可）_ 指定されている場合、このパスステップはオーダーブックを通じた通貨の変換を表します。指定される通貨は新しい通貨を表します。このステップに`account`フィールドが指定されている場合は、このフィールドを指定しないでください。 |
|
||||
| `issuer` | 文字列 - アドレス | _（省略可）_ 指定されている場合、このパスステップは通貨の変換を表し、このアドレスは新しい通貨のイシュアーを定義します。XRP以外の`currency`のステップでこのフィールドが省略されている場合、パスの直前のステップがイシュアーを定義します。`currency`が省略され、このフィールドが指定されている場合、イシュアーが異なる同名の通貨間でオーダーブックを使用するパスステップを示します。`currency`がXRPの場合は省略する必要があります。このステップに`account`フィールドが指定されている場合は、このフィールドを指定しないでください。 |
|
||||
| `type` | 整数 | **廃止予定**_（省略可）_ 他にどのフィールドが指定されているかを示します。 |
|
||||
| `type_hex` | 文字列 | **廃止予定**: _（省略可）_`type`フィールドの16進数表現です。 |
|
||||
|
||||
要約すると、以下のフィールドの組み合わせが有効であり、またオプションで`type`、`type_hex`のいずれかまたは両方を指定できます。
|
||||
|
||||
- `account` のみ
|
||||
- `currency` のみ
|
||||
- `currency` と`issuer`（`currency`がXRP以外の場合）
|
||||
- `issuer` のみ
|
||||
|
||||
パスステップで`account`、`currency`、`issuer`の各フィールドを上記以外の方法で指定することは無効です。
|
||||
|
||||
パスセットのバイナリシリアル化に使用される`type`フィールドは、実際には1つの整数上でビット演算により作成されます。ビットの定義は次のとおりです。
|
||||
|
||||
| 値（16進数） | 値（10進数） | 説明 |
|
||||
|-------------|-----------------|-------------|
|
||||
| 0x01 | 1 | アドレスの変更（Rippling）:`account`フィールドが指定されています。 |
|
||||
| 0x10 | 16 | 通貨の変更:`currency`フィールドが指定されています。 |
|
||||
| 0x20 | 32 | イシュアーの変更:`issuer`フィールドが指定されています。 |
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
86
content/concepts/issued-currencies/rippling.ja.md
Normal file
86
content/concepts/issued-currencies/rippling.ja.md
Normal file
@@ -0,0 +1,86 @@
|
||||
# Rippling
|
||||
|
||||
XRP Ledgerでは、「Rippling」とは同一通貨の[トラストライン](trust-lines-and-issuing.html)を有する複数の接続当事者間での非可分なネット決済のプロセスを指しています。Ripplingは発行済み通貨の基幹的なプロセスです。Ripplingを利用すれば、同一イシュアーを信頼するユーザーは、そのイシュアーを受動的な仲介機関として発行済み残高を相互に送金できるようになります。Ripplingは、受動的かつ双方向の[通貨取引オーダー](offers.html)のようなもので、制限がなく、通貨コードが同一でイシュアーが異なる2つの通貨間の為替レートは1:1です。
|
||||
|
||||
Ripplingは、支払[パス](paths.html)でのみ発生します。
|
||||
|
||||
発行アカウント以外のアカウントでは、Ripplingが望ましくない場合があります。Ripplingを使えば、他のユーザーが同一通貨のイシュアー間で債権債務を移動できるようになるためです。このため、アカウントの[DefaultRippleフラグ](#defaultrippleフラグ)を有効にして、アカウントがデフォルトでRipplingを有効にしない限り、デフォルトでは[NoRippleフラグ](#norippleフラグ)により着信トラストラインでのRipplingが無効になっています。
|
||||
|
||||
**注意:** 別のアドレスへのトラストラインを作成する場合、そのトラストラインのあなたの側でRipplingをブロックするには、tfSetNoRippleフラグを明示的に有効にする必要があります。
|
||||
|
||||
## Ripplingの例
|
||||
|
||||
「Rippling」は、支払いを行うために複数のトラストラインが調整されたときに発生します。たとえば、AliceがCharlieにお金を借りており、さらにAliceはBobからもお金を借りている場合、XRP Ledgerではトラストラインは次のようになります:
|
||||
|
||||
|
||||
|
||||
BobがCharlieに$3を支払いたい場合、BobはAliceに対して「Alice、君に貸しているお金の中から$3をCharlieに支払ってくれ。」と言えます。AliceはBobに借りているお金の一部をCharlieに送金します。最終的にはトラストラインは次のようになります。
|
||||
|
||||
|
||||
|
||||
2つのアドレスが、アドレス間のトラストライン上の残高を調整することで相互に支払うこのプロセスを「Rippling」と呼びます。これはXRP Ledgerの有用で重要な機能です。Ripplingは、同一の[通貨コード][]を使用するトラストラインによってアドレスがリンクされている場合に起こります。イシュアーが同一でなくてもかまいません。実際、大規模なチェーンでは常にイシュアーが変更されます。
|
||||
|
||||
## NoRippleフラグ
|
||||
|
||||
発行アカウント以外のアカウント、特に手数料やポリシーが異なる複数のイシュアーの残高を保有している流動性プロバイダーは、一般的に残高がRipplingされることを望みません。
|
||||
|
||||
「NoRipple」フラグは、トラストライン上の設定です。2つのトラストラインの両方で、同じアドレスによってNoRippleが有効に設定されている場合、第三者からの支払を、これらのトラストラインでこのアドレスを通じて「Rippling」することはできません。これにより、同一通貨の複数イシュアー間で流動性プロバイダーの残高が予期せず移動されるのを防ぎます。
|
||||
|
||||
アカウントは1つのトラストラインでNoRippleを無効にできます。これにより、そのトラストラインを含む任意のペアを通じてのRipplingが可能になります。アカウントにてデフォルトでRipplingを有効にするには、[DefaultRippleフラグ](#defaultrippleフラグ)を有効にします。
|
||||
|
||||
たとえば、Emilyが2つの異なる金融機関から発行されたお金を保有しているとします。
|
||||
|
||||
|
||||
|
||||
CharlieはDanielに支払うため、Emilyのアドレスを通じてRipplingします。たとえば、CharlieがDanielに$10を支払うとします:
|
||||
|
||||
|
||||
|
||||
この場合、CharlieやDanielと面識のないEmilyは驚く可能性があります。さらに、金融機関Aが金融機関Bよりも高い出金手数料をEmilyに請求した場合、Emilyがコストを負担することになる可能性があります。NoRippleフラグはこの状況を回避するためのフラグです。Emilyが両方のトラストラインでNoRippleフラグを設定していれば、この2つのトラストラインを使用しているEmilyのアドレスを通じて、支払がRipplingされることはありません。
|
||||
|
||||
例:
|
||||
|
||||
|
||||
|
||||
このように、CharlieがEmilyのアドレスを通じてRipplingし、Danielに支払うという上記のシナリオは、不可能になります。
|
||||
|
||||
### 詳細
|
||||
|
||||
NoRippleフラグにより特定のパスが無効になり、無効になったパスは支払に使用できなくなります。パスが無効であると見なされるのは、パスが、あるアドレスに対してNoRippleが有効となっているトラストラインを通じて、そのアドレスノードに入り**かつ**そのノードから出た場合に限られます。
|
||||
|
||||
|
||||
|
||||
|
||||
## DefaultRippleフラグ
|
||||
|
||||
DefaultRippleフラグは、デフォルトで着信トラストラインでのRipplingを有効にするアカウント設定です。ゲートウェイやその他の通貨イシュアーは、顧客が通貨を相互に送金できるようにするには、このフラグを有効にする必要があります。
|
||||
|
||||
アカウントのDefaultRipple設定は、他者があなたに対してオープンしたトラストラインにのみ影響し、あなたが作成するトラストラインには影響しません。アカウントのDefaultRipple設定を変更する場合、変更前に作成したトラストラインでは既存のNoRipple設定が維持されます。アドレスの新しいデフォルトに合わせてトラストラインのNoRipple設定を変更するには、[TrustSetトランザクション][]を使用します。
|
||||
|
||||
詳細は、[「XRP Ledgerゲートウェイの開設」のDefaultRipple](become-an-xrp-ledger-gateway.html#defaultripple)を参照してください。
|
||||
|
||||
|
||||
## NoRippleを使用する
|
||||
<!--{# TODO: move these things into their own tutorials #}-->
|
||||
|
||||
### NoRippleを有効/無効にする
|
||||
|
||||
トラストライン上のNoRippleフラグは、トラストライン上のアドレスの残高がプラスまたはゼロの場合に限り、有効にできます。これにより、この機能を悪用してトラストラインの残高に示される債務を不履行にすることができなくなります。（ただし、アドレスを放棄すれば債務を不履行にできます。）
|
||||
|
||||
[`rippled` API](rippled-api.html)でNoRippleフラグを有効にするには、`tfSetNoRipple`フラグを設定した[TrustSetトランザクション][]を送信します。NoRippleを無効にする（Ripplingを有効にする）には、`tfClearNoRipple`フラグを使用します。
|
||||
|
||||
[RippleAPI](rippleapi-reference.html)でNoRippleフラグを有効にするには、トラストラインの`ripplingDisabled` フィールドを`true`に設定して[Trustlineトランザクション](rippleapi-reference.html#preparetrustline)を送信します。
|
||||
|
||||
|
||||
### NoRippleステータスの確認
|
||||
|
||||
相互に信頼し合っている2つのアカウントの場合、NoRippleフラグはアカウントごとに管理されます。
|
||||
|
||||
[`rippled` API](rippled-api.html)でアドレスに関連付けられているトラストラインを確認するには、[account_linesメソッド][]を使用します。各トラストラインの`no_ripple`フィールドには、現在のアドレスがそのトラストラインに対してNoRippleフラグを有効にしているか否かが表示され、`no_ripple_peer`フィールドには、取引相手がNoRippleフラグを有効にしているか否かが表示されます。
|
||||
|
||||
[RippleAPI](rippleapi-reference.html)でアドレスに関連付けられているトラストラインを確認するには、[getTrustlines](rippleapi-reference.html#gettrustlines)メソッドを使用します。各トラストラインの`ripplingDisabled`フィールドには、現在のアドレスがそのトラストラインに対してNoRippleフラグを有効にしているか否かが表示され、`counterparty.ripplingDisabled`フィールドには、取引相手がNoRippleフラグを有効にしているか否かが表示されます。
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
55
content/concepts/issued-currencies/transfer-fees.ja.md
Normal file
55
content/concepts/issued-currencies/transfer-fees.ja.md
Normal file
@@ -0,0 +1,55 @@
|
||||
# 送金手数料
|
||||
|
||||
[XRP Ledgerで通貨を発行する金融機関](become-an-xrp-ledger-gateway.html)は、XRP Ledgerの`TransferRate`設定を使用して、 その金融機関が発行する通貨を送金するユーザーに対し _送金手数料_ を請求できます。この送金の送金元からは送金手数料に基づくパーセンテージが引き落とされ、送金先には予定額が入金されます。差額が送金手数料です。送金手数料は発行アドレスの資産となり、XRP Ledgerではこれ以上追跡されません。発行アカウントとの _直接_ の送金と入金には送金手数料は適用されませんが、[運用アドレス][]から別のユーザーへの送金には送金手数料が適用されます。
|
||||
|
||||
[運用アドレス]: issuing-and-operational-addresses.html
|
||||
[発行アドレス]: issuing-and-operational-addresses.html
|
||||
|
||||
XRPにはイシュアーがいないため、送金手数料が発生することはありません。
|
||||
|
||||
たとえばACME BankがACMEイシュアンスの送金手数料を0.5%に設定するとします。支払いの受取人が2 EUR.ACMEを受領するには、送金元が2.01 EUR.ACMEを送金する必要があります。このトランザクションの後、XRP LedgerのACMEの債務残高は0.01€減少します。つまり、ACMEはそのXRP Ledgerイシュアンスの担保となるアカウントで当該の額を保有する必要がありません。
|
||||
|
||||
次の図は、XRP LedgerによるAliceからCharlieへの2 EUR.ACMEの支払い（送金手数料1%）を示します。
|
||||
|
||||
|
||||
|
||||
## ペイメントパスでの送金手数料
|
||||
|
||||
<!--{# TODO: Update this for OnwerPaysFee amendment when that gets added #}-->
|
||||
|
||||
送金手数料は、各送金においてイシュアンスが発行アカウントを通じて当事者間を移動するたびに適用されます。さらに複雑なトランザクションでは、手数料が複数回適用されます。送金手数料は、送金の終わりの時点から逆方向に適用されるので、最終的には支払いの送金者がすべての手数料をカバーするのに十分な額を送金する必要があります。次に例を示します。
|
||||
|
||||
|
||||
|
||||
このシナリオでは、ACMEが発行したEURをSalazar（送金元）が保有しており、WayGateが発行した100 USDをRosa（受取人）に送金したいと思っています。FXMakerはオーダーブックで最も良いレート（1 USD.WayGate = 0.9 EUR.ACME）のオファーを提供する通貨取引業者です。もし手数料がなければ、Salazarは90 EURを送金すればRosaに100 USDを送金することができます。しかしながら、ACMEで1%の送金手数料が発生し、WayGateで0.2%の送金手数料が発生します。つまり、次のようになります。
|
||||
|
||||
* Rosaが100 USD.WayGateを受領するには、FXMakerから100.20 USD.WayGateを送金する必要があります。
|
||||
* 100.20 USD.WayGateを送金する場合のFXMakerの現在の買値は90.18 EUR.ACMEです。
|
||||
* FXMakerが90.18 EUR.ACMEを受領するには、Salazarが91.0818 EUR.ACMEを送金する必要があります。
|
||||
|
||||
# 技術詳細
|
||||
|
||||
送金手数料は[発行アドレス][]の設定により表されます。送金手数料には、0%未満の値と100%を超える値は指定できず、0.0000001%の位までで切り捨てられます。TransferRate設定は同一アカウントにより発行されるすべての通貨に適用されます。通貨によって異なる送金手数料のパーセンテージを適用するには、通貨ごとに異なる[発行アドレス][発行アドレス]を使用します。
|
||||
|
||||
**注記:**`rippled`v0.80.0で導入され2017-11-14に有効となった[fix1201 Amendment](amendments.html)により、最大送金手数料は実効限度である約329%（32ビット整数の最大サイズに基づく）から100%に引き下げられました。送金手数料の設定が100%（`TransferRate`が`2000000000`）を上回るアカウントがレジャーにまだ含まれている可能性があります。すでに設定されている手数料はすべて、規定のレートで引き続き運用されます。
|
||||
|
||||
## RippleAPI
|
||||
|
||||
RippleAPIでは、送金手数料は`transferRate`フィールドに10進数で指定され、この数は受取人が同一通貨を1単位受領できるよう送金する必要のある額を表します。`transferRate`が`1.005`の場合、送金手数料0.5%に相当します。デフォルトでは`transferRate`は手数料なしに設定されています。`transferRate`には、`1.0`未満の値と`2.0`を上回る値は指定できません。送金手数料は、10桁の有効数字に丸められます（1の位の数字を含む）。値`null`は手数料なしの特殊なケースであり、`1.0`に相当します。
|
||||
|
||||
金融機関は、[発行アドレス][]から[Settingsトランザクション](rippleapi-reference.html#settings)を送信して、イシュアンスの`transferRate`を変更することができます。
|
||||
|
||||
アカウントの`transferRate`を確認するには、[getSettingsメソッド](rippleapi-reference.html#getsettings)を使用します。
|
||||
|
||||
## rippled
|
||||
|
||||
`rippled`のJSON-RPC APIおよびWebSocket APIでは、送金手数料は`TransferRate`フィールドに10進数で指定され、この数字は受取人が同一通貨を10億単位受領できるよう送金する必要のある額を表します。`TransferRate`が`1005000000`の場合、送金手数料0.5%に相当します。デフォルトでは`TransferRate`は手数料なしに設定されています。`TransferRate`には、`1000000000`（手数料「0%」）未満の値と`2000000000`（手数料「100%」）を上回る値は指定できません。値`0`は手数料なしの特殊なケースであり、`1000000000`に相当します。
|
||||
|
||||
金融機関は、[発行アドレス][]から[AccountSetトランザクション][]を送信して、イシュアンスの`TransferRate`を変更することができます。
|
||||
|
||||
アカウントの`TransferRate`を確認するには、[account_infoメソッド][]を使用します。`TransferRate`が省略されている場合は、手数料はありません。
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -0,0 +1,24 @@
|
||||
# トラストラインと発行
|
||||
|
||||
XRP Ledgerの[発行済み通貨](issued-currencies.html)は、XRP Ledger外部で _ゲートウェイ_ が保有する価値をしばしば表します。ユーザーがXRP Ledgerの残高をイシュアーに返却して清算するときには、XRP Ledger内でこれらの資金を発行するアドレスが、XRP Ledger外部で残高を払い戻すことが期待されます。
|
||||
|
||||
コンピュータープログラムは外界で約束を守ることを誰にも強制できないため、トラストラインは、イシュアーがあなたの代わりに保有する価値の量として、あなたが信頼できる量を設定する手段となります。信用のある大手金融機関は、お金のないルームメートに比べれば返済能力は高いため、トラストラインごとに異なる限度を設定して、XRP Ledgerでイシュアーがあなたから「借用」できる上限額を指定できます。イシュアーが債務不履行になった場合や、倒産した場合には、XRP Ledgerでの保有残高をその他の等価の資産と交換できなくなるため、設定した上限額まで失う可能性があります。（XRP Ledgerで引き続き発行済み通貨を保持または取引できますが、発行済み通貨に価値があると見なされる理由がなくなる可能性があります。）
|
||||
|
||||
次の2つの場合、残高が限度額を _超過_ しても、トラストラインにその残高を保有できます。[取引](decentralized-exchange.html)によりその通貨をさらに積み増しする場合と、トラストラインの限度を引き下げる場合。
|
||||
|
||||
トラストラインはレジャーのスペースを使用するため、[トラストラインにより、アカウントの準備金として保有する必要のあるXRPが増加します](reserves.html)。これは、信頼を受けているアカウントではなく、信頼を拡大しているアカウントに適用されます。
|
||||
|
||||
各トラストラインは、特定の[通貨コード][]に固有です。2つのアカウント間に作成できる各種通貨コードのトラストラインの数に制限はありませんが、どの通貨コードについても、作成できるトラストラインは1方向に1つだけです。
|
||||
|
||||
## トラストラインの設定
|
||||
|
||||
トラストラインは、レジャーの状態データでは[RippleStateオブジェクト](ripplestate.html)として表されます。1つのRippleStateオブジェクトは、一方向または両方向のトラストラインの可能性を表します。このオブジェクトにはトラストラインのそれぞれのサイドに対する制限やその他の設定が含まれていますが、両サイドは1つの正味残高を共有しています。
|
||||
|
||||
トラストラインの設定がデフォルトの状態である場合、トラストラインがないのと同等です。
|
||||
|
||||
[NoRippleフラグ](rippling.html)（デフォルトの設定はDefaultRippleフラグの設定に応じて異なる）を除き、トラストラインフラグのすべてのフラグは、デフォルトでオフになっています。
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
141
content/concepts/payment-system-basics/accounts/accounts.ja.md
Normal file
141
content/concepts/payment-system-basics/accounts/accounts.ja.md
Normal file
@@ -0,0 +1,141 @@
|
||||
# アカウント
|
||||
|
||||
XRP Ledgerの「アカウント」は、XRPの所有者と[トランザクション](transaction-formats.html)の送信者を表します。アカウントの主な要素は次のとおりです。
|
||||
|
||||
- 識別用の**アドレス**。例えば、 `rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn`
|
||||
- **XRPの残高**。このXRPの一部は、[準備金](reserves.html)用に確保されています。
|
||||
- **シーケンス番号**は1から始まり、このアカウントからトランザクションが送信されるたびに1つ増加します。トランザクションのシーケンス番号がその送信者の次のシーケンス番号と一致しない限り、トランザクションをレジャーに含めることはできません。
|
||||
- このアカウントと残高に影響を及ぼした**取引の履歴**。
|
||||
- [取引の承認](transaction-basics.html#取引の承認)方法。以下に例を示します。
|
||||
- アカウント固有のマスターキーのペア。（[無効](accountset.html)にできますが、変更はできません。）
|
||||
- [ローテーションで使用](setregularkey.html)できる「レギュラー」キーペア。
|
||||
- [マルチ署名](multi-signing.html)の署名者のリスト。（アカウントのコアデータとは別に保存されます。）
|
||||
|
||||
アカウントのコアデータは、レジャーのデータツリーの[AccountRoot](accountroot.html)レジャーのオブジェクトタイプに保存されます。アカウントは、他の複数のタイプのデータの所有者（または部分的な所有者）になることもできます。
|
||||
|
||||
**ヒント:** XRP Ledgerの「アカウント」は、財務上の用途（例:「銀行口座」）やコンピューター上の用途（例:「UNIXアカウント」）で使用されます。XRP以外の通貨および資産はXRP Ledgerアカウント自体には保存されません。そのような資産はそれぞれ、両当事者を結ぶ「トラストライン」と呼ばれる会計関係に保存されます。
|
||||
|
||||
### アカウントの作成
|
||||
|
||||
「アカウント作成」専用のトランザクションはありません。Paymentトランザクション でまだアカウントを所有していない数学的に有効なアドレスに[アカウントの準備金](reserves.html)以上のXRPが送信されると、[Paymentトランザクション][]で自動的に新しいアカウントが作成されます。これはアカウントの _資金提供_ と呼ばれ、レジャーに[AccountRootオブジェクト](accountroot.html)が作成されます。それ以外のトランザクションでアカウントを作成することはできません。
|
||||
|
||||
**注意:** アカウントを資金提供することによって、そのアカウントに対して特別な権限を持つことには**なりません**。アカウントのアドレスに対応するシークレットキーを持っている人なら誰でも、アカウントとそれに含まれるすべてのXRPの完全制御権を持っています。一部のアドレスでは、誰もシークレットキーを持っていない場合があります。その場合、アカウントは[ブラックホール](#特別なアドレス)になり、XRPは永久に失われます。
|
||||
|
||||
XRP Ledgerでアカウントを取得する一般的な方法は次のとおりです。
|
||||
|
||||
1. ランダム性の強いソースからキーペアを生成し、そのキーペアのアドレスを計算します。（例えば、[wallet_proposeメソッド][]を使用して計算することができます。）
|
||||
|
||||
2. XRP Ledgerにアカウントをすでに持っているユーザーに、生成したアドレスにXRPを送信してもらいます。
|
||||
|
||||
- 例えば、一般の取引所でXRPを購入し、その取引所から、指定したアドレスにXRPを引き出すことができます。
|
||||
|
||||
**注意:** 自身のXRP Ledgerアドレスで初めてXRPを受け取る場合は[アカウントの準備金](reserves.html)（現在は20 XRP）を支払う必要があります。この金額のXRPは無期限に使用できなくなります。一方で、一般の取引所では通常、顧客のXRPはすべて、共有されたいくつかのXRP Ledgerアカウントに保有されているため、顧客はその取引所で個々のアカウントの準備金を支払う必要はありません。引き出す前に、XRP Ledgerに直接アカウントを保有することが、金額に見合う価値があるかどうかを検討してください。
|
||||
|
||||
## アドレス
|
||||
|
||||
{% include '_snippets/data_types/address.md' %}
|
||||
|
||||
有効なアドレスに資金供給することで、そのアドレスを[XRP Ledgerのアカウントにする](#アカウントの作成)ことができます。[レギュラーキー](setregularkey.html)または[署名者リスト](multi-signing.html)のメンバーを表すために資金供給されていないアドレスを使用することもできます。資金供給されたアカウントのみがトランザクションの送信者になることができます。
|
||||
|
||||
キーペアを始め、有効なアドレスの作成は、厳密な数学的演算です。キーペアの生成と、そのアドレスの計算は完全にオフラインで行うことができます。XRP Ledgerやその他の関係者と通信する必要はありません。公開鍵からアドレスへの変換には一方向のハッシュ関数が含まれるため、公開鍵がアドレスと一致することは確認できますが、アドレスのみから公開鍵を導出することはできません。（このことが、署名付きのトランザクションに送信者の公開鍵 _と_ アドレスが含まれる理由の1つとなっています。）
|
||||
|
||||
XRP Ledgerアドレスの計算方法の技術的な詳細については、[アドレスのエンコード](#アドレスのエンコード)を参照してください。
|
||||
|
||||
|
||||
### 特別なアドレス
|
||||
|
||||
XRP Ledgerでは、過去の使用という点で、一部のアドレスに特別な意味があります。多くの場合、これらのアドレスは「ブラックホール」アドレスです。つまり、このアドレスは既知のシークレットキーから派生したものではありません。アドレスのみからシークレットキーを推測することは事実上不可能なため、ブラックホールアドレスが保有しているXRPは永久に失われます。
|
||||
|
||||
| アドレス | 名前 | 意味 | ブラックホール？ |
|
||||
|-----------------------------|------|---------|-------------|
|
||||
| rrrrrrrrrrrrrrrrrrrrrhoLvTp | ACCOUNT\_ZERO | 値`0`を[base58][]形式にエンコードしたXRP Ledgerのアドレス。ピアツーピア通信では、このアドレスは、XRPの発行者として`rippled`で使用されます。 | はい |
|
||||
| rrrrrrrrrrrrrrrrrrrrBZbvji | ACCOUNT\_ONE | 値`1`を[base58][]形式にエンコードしたXRP Ledgerのアドレス。レジャーの[RippleState項目](ripplestate.html)では、このアドレスは、トラストライン残高の発行者のプレースホルダーとして使用されます。 | はい |
|
||||
| rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh | ジェネシスアカウント | `rippled`で新しいジェネシスレジャーが一から開始される場合（例えば、スタンドアロンモード）、このアカウントはすべてのXRPを保持します。このアドレスは、シード値「masterpassphrase」から生成されており、この値は[ハードコーディング](https://github.com/ripple/rippled/blob/94ed5b3a53077d815ad0dd65d490c8d37a147361/src/ripple/app/ledger/Ledger.cpp#L184)されています。 | いいえ |
|
||||
| rrrrrrrrrrrrrrrrrNAMEtxvNvQ | Ripple名予約のブラックホール | 以前は、Rippleでは、このアカウントにXRPを送信してRipple名を予約するようユーザーに求めていました。| はい |
|
||||
| rrrrrrrrrrrrrrrrrrrn5RM1rHd | NaNアドレス | 以前のバージョンの[ripple-lib](https://github.com/ripple/ripple-lib)では、XRP Ledgerの[base58][]文字列エンコード形式を使用して、値[NaN](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/NaN)をエンコードするときにこのアドレスを生成しました。 | はい |
|
||||
|
||||
|
||||
## アカウントの永続性
|
||||
|
||||
一度作成されたアカウントはXRP Ledgerのデータツリーに永続的に存在します。これは、古いトランザクションを2回処理できないように、トランザクションの現在のシーケンス番号を永続的に追跡する必要があるためです。
|
||||
|
||||
Bitcoinや他の多くの暗号資産とは異なり、XRP Ledgerの公開レジャーチェーンの新しい各バージョンにはレジャーの詳細なステータスが含まれており、このサイズは、新規アカウントが増えるごとに大きくなります。そのため、Rippleでは、本当に必要でない限り、新しいアカウントを作成することは推奨していません。多くのユーザーに代わって価値を送受信する金融機関などは、XRP Ledgerでは1つ（または少数）のアカウントのみを使用し、顧客との間の個別の決済を区別するために[**ソースタグ**と**宛先タグ**](become-an-xrp-ledger-gateway.html#source-and-destination-tags)を使用できます。
|
||||
|
||||
|
||||
## トランザクション履歴
|
||||
|
||||
XRP Ledgerでは、トランザクション（取引）履歴をトランザクションの「スレッド」によって追跡することができます。これはトランザクションの識別用のハッシュとレジャーインデックスにリンクされています。`AccountRoot`レジャーオブジェクトには、それを最後に修正したトランザクションの識別用のハッシュとレジャーが含まれます。そのトランザクションのメタデータには、`AccountRoot`ノードの前の状態が含まれているため、この方法で1つのアカウントの履歴を繰り返すことができます。このトランザクション履歴には、`AccountRoot`ノードを直接変更するトランザクションが含まれます。以下に例を示します。
|
||||
|
||||
- アカウントによって送信されるトランザクション。アカウントの`Sequence`番号が変更されるため。このようなトランザクションでは、[トランザクションコスト](transaction-cost.html)によりアカウントのXRP残高も変更されます。
|
||||
- アカウントのXRP残高を変更したトランザクション。例えば、着信する[Paymentトランザクション][]や他のタイプの取引（例:[PaymentChannelClaim][]や[EscrowFinish][]）。
|
||||
|
||||
アカウントの _概念的な_ トランザクション履歴には、アカウントの所有オブジェクトとXRP以外の残高を変更したトランザクションも含まれます。これらのオブジェクトは別個のレジャーオブジェクトであり、それぞれに影響を及ぼした独自のトランザクションスレッドが含まれます。アカウントのレジャーの履歴全体がある場合は、それをたどって、その履歴によって作成または変更されたレジャーオブジェクトを見つけることができます。「完全」なトランザクション履歴には、トランザクションで所有されているオブジェクトの履歴が含まれます。例を以下に示します。
|
||||
|
||||
- `RippleState` オブジェクト（トラストライン）。アカウントに関連付けられています。
|
||||
- `DirectoryNode` オブジェクト（特にアカウントの所有オブジェクトを追跡する所有者ディレクトリ）。
|
||||
- `Offer` オブジェクト。分散型取引所でのアカウントの未処理の取引注文を表すオブジェクト。
|
||||
- `PayChannel` アカウントとの間の非同期のPayment Channelを表すオブジェクト。
|
||||
- `Escrow` 時間または暗号条件によってロックされ、アカウントとの間の保留中の支払いを表すオブジェクト。
|
||||
- `SignerList` [マルチ署名](multi-signing.html)によってアカウントのトランザクションを承認できるアドレスのリストを表すオブジェクト。
|
||||
|
||||
これらの各オブジェクトの詳細については、[レジャーフォーマットのリファレンス](ledger-data-formats.html)を参照してください。
|
||||
|
||||
|
||||
## アドレスのエンコード
|
||||
|
||||
**ヒント:** これらの技術的な詳細は、XRP Ledgerとの互換性を保つために低レベルのライブラリソフトウェアを構築しているユーザーのみを対象としています。
|
||||
|
||||
[[ソース]<br>](https://github.com/ripple/rippled/blob/35fa20a110e3d43ffc1e9e664fc9017b6f2747ae/src/ripple/protocol/impl/AccountID.cpp#L109-L140 "Source")
|
||||
|
||||
XRP Ledgerのアドレスは、次のRipple _ディクショナリー_ の[base58](https://en.wikipedia.org/wiki/Base58)を使用してエンコードされています。`rpshnaf39wBUDNEGHJKLM4PQRST7VWXYZ2bcdeCg65jkm8oFqi1tuvAxyz`。XRP Ledgerはbase58でいくつかのタイプのキーをエンコードするため、それらを区別するためにエンコードされたデータの前に1バイトの「タイププレフィクス」（「バージョンプレフィクス」とも呼ばれます）を付けます。タイププレフィクスによりアドレスは通常、base58形式の異なる文字で始まります。
|
||||
|
||||
次の図は、キーとアドレスの関係を示しています。
|
||||
|
||||
|
||||
|
||||
XRP Ledgerアドレスの計算式は次のとおりです。コード例全体については、[`encode_address.js`](https://github.com/ripple/ripple-dev-portal/blob/master/content/_code-samples/address_encoding/encode_address.js)を参照してください。
|
||||
|
||||
1. 次の必須アルゴリズムをインポートします。SHA-256、RIPEMD160、base58。base58のディクショナリーを設定します。
|
||||
|
||||
'use strict';
|
||||
const assert = require('assert');
|
||||
const crypto = require('crypto');
|
||||
const R_B58_DICT = 'rpshnaf39wBUDNEGHJKLM4PQRST7VWXYZ2bcdeCg65jkm8oFqi1tuvAxyz';
|
||||
const base58 = require('base-x')(R_B58_DICT);
|
||||
|
||||
assert(crypto.getHashes().includes('sha256'));
|
||||
assert(crypto.getHashes().includes('ripemd160'));
|
||||
|
||||
2. 33バイトのECDSA secp256k1公開鍵、または32バイトのEd25119公開鍵で始めます。Ed25519キーの場合は、キーの前にバイト`0xED`を付けます。
|
||||
|
||||
const pubkey_hex =
|
||||
'ED9434799226374926EDA3B54B1B461B4ABF7237962EAE18528FEA67595397FA32';
|
||||
const pubkey = Buffer.from(pubkey_hex, 'hex');
|
||||
assert(pubkey.length == 33);
|
||||
|
||||
3. 公開鍵のSHA-256ハッシュの[RIPEMD160](https://en.wikipedia.org/wiki/RIPEMD)ハッシュを計算します。この値は「Account ID」です。
|
||||
|
||||
const pubkey_inner_hash = crypto.createHash('sha256').update(pubkey);
|
||||
const pubkey_outer_hash = crypto.createHash('ripemd160');
|
||||
pubkey_outer_hash.update(pubkey_inner_hash.digest());
|
||||
const account_id = pubkey_outer_hash.digest();
|
||||
|
||||
4. アカウントIDのSHA-256ハッシュのSHA-256ハッシュを計算します。最初の4バイトを使用ます。この値が「チェックサム」です。
|
||||
|
||||
const address_type_prefix = Buffer.from([0x00]);
|
||||
const payload = Buffer.concat([address_type_prefix, account_id]);
|
||||
const chksum_hash1 = crypto.createHash('sha256').update(payload).digest();
|
||||
const chksum_hash2 = crypto.createHash('sha256').update(chksum_hash1).digest();
|
||||
const checksum = chksum_hash2.slice(0,4);
|
||||
|
||||
5. ペイロードとチェックサムを連結します。連結バッファーのbase58値を計算します。この結果が、該当のアドレスになります。
|
||||
|
||||
const dataToEncode = Buffer.concat([payload, checksum]);
|
||||
const address = base58.encode(dataToEncode);
|
||||
console.log(address);
|
||||
// rDTXLQ7ZKZVKz33zJbHjgVShjsBnqMBhmN
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -0,0 +1,121 @@
|
||||
# 暗号鍵
|
||||
|
||||
XRP Ledgerでは、トランザクションによる一連の具体的なアクションの実行が承認されていることを、デジタル署名によって証明します。署名されたトランザクションのみがネットワークに配信され、検証済みレジャーに取り込まれます。 <!-- STYLE_OVERRIDE: is authorized to -->
|
||||
|
||||
すべてのデジタル署名は、トランザクションの送信側アカウントに関連付けられている暗号鍵ペアに基づいています。キーペアはXRP Ledgerでサポートされている[暗号化署名アルゴリズム](#署名アルゴリズム)を使用して生成できます。キーペアの生成に使用されたアルゴリズムの種類にかかわらず、キーペアは[マスターキーペア](#マスターキーペア)、[レギュラーキーペア](#レギュラーキーペア)、または[署名者リスト](multi-signing.html)のメンバーとして使用できます。
|
||||
|
||||
**警告:** 秘密鍵のセキュリティを適切に維持することが重要です。デジタル署名は、あなたがトランザクション送信する権限を有していることをXRP Ledgerに対して検証できる唯一の手段であり、レジャーに提出されたトランザクションの取り消しや無効化を行う権限を有する管理者は存在しません。あなたのXRP Ledgerアカウントの秘密鍵があなた以外の何者かに知られた場合、その人物はあなたと同様にデジタル署名を作成し、トランザクションを承認することができます。
|
||||
|
||||
## キーの生成
|
||||
|
||||
[`wallet_propose`](wallet_propose.html)メソッドを使用してキーペアを生成します。以下は、`wallet_propose`の応答例です。
|
||||
|
||||
```
|
||||
{
|
||||
"result": {
|
||||
"account_id": "rDGnaDqJczDAjrKHKdhGRJh2G7zJfZhj5q",
|
||||
"key_type": "secp256k1",
|
||||
"master_key": "COON WARN AWE LUCK TILE WIRE ELI SNUG TO COVE SHAM NAT",
|
||||
"master_seed": "sstV9YX8k7yTRzxkRFAHmX7EVqMfX",
|
||||
"master_seed_hex": "559EDD35041D3C11F9BBCED912F4DE6A",
|
||||
"public_key": "aBQXEw1vZD3guCX3rHL8qy8ooDomdFuxZcWrbRZKZjdDkUoUjGVS",
|
||||
"public_key_hex": "0351BDFB30E7924993C625687AE6127034C4A5EBA78A01E9C58B0C46E04E3A4948"
|
||||
},
|
||||
"status": "success",
|
||||
"type": "response"
|
||||
}
|
||||
```
|
||||
|
||||
この応答には、キーペア（さまざまなフォーマットの秘密鍵と公開鍵）と`account_id`が含まれています。
|
||||
|
||||
**秘密鍵**
|
||||
|
||||
`master_key`、`master_seed`、および`master_seed_hex`は、トランザクションの署名に使用できる異なるフォーマットの秘密鍵です。キーの先頭に`master_`が付いていますが、これらのキーは必ずしもアカウントのマスターキーというわけではありません。ここでは、`master_`というプレフィックスは、そのキーの秘密鍵としての役割を示します。`master_seed`はマスターシードで、そこからこのアカウントに関するその他のあらゆる情報が引き出されます。
|
||||
|
||||
**公開鍵**
|
||||
|
||||
`public_key`と`public_key_hex`は異なるフォーマットの公開鍵で、`public_key_hex`はトランザクションに署名された秘密鍵に対応する公開鍵です。`public_key`と`public_key_hex`はいずれも`master_seed`から生成されます。
|
||||
|
||||
**account_id**
|
||||
|
||||
`account_id`は[公開鍵から生成され](accounts.html#アドレスのエンコード)、アカウントがXRP Ledgerに作成される *可能性* を示します。`account_id`が存在していても、`account_id`が最初の XRPでの支払いを受領するまでは、実際のアカウントはXRP Ledgerに存在しません。さらに`account_id`は、資金を供給するトランザクションを受領して、アカウントが作成されるまでは、トランザクションを送信することができません。
|
||||
|
||||
ただし、（資金供給されたアカウントのない）`account_id`は、既存の別のアカウントのトランザクションを承認する際に[レギュラーキー](#レギュラーキーペア)または[署名者リストのメンバー](multi-signing.html)として使用できます。
|
||||
|
||||
資金供給されたアカウントを作成してレジャーに保管するには、`account_id`が、[必要準備金](reserves.html)を満たすのに十分なXRPを供給する[`Payment`トランザクションを受領する](payment.html#アカウントの作成)必要があります。
|
||||
|
||||
`wallet_propose`応答についての詳細は、[`wallet_propose`](wallet_propose.html)を参照してください。
|
||||
|
||||
生成されたキーペアは、[マスターキーペア](#マスターキーペア)、[レギュラーキーペア](#レギュラーキーペア)、または[署名者リストメンバー](multi-signing.html)のいずれかとして使用できます。
|
||||
|
||||
**キータイプ**
|
||||
|
||||
`key_type`フィールドは、このキーペアの生成に使用された[暗号化署名アルゴリズム](#署名アルゴリズム)を示します。[wallet_proposeメソッド][]を使用したキーペアの生成を要求するときに、`key_type`を指定できます。
|
||||
|
||||
|
||||
## マスターキーペア
|
||||
|
||||
マスターキーペアは秘密鍵と公開鍵からなります。マスターキーペアの秘密鍵は、レギュラーキーペアが署名できるすべてのトランザクションに署名できる他、以下の操作の実行に使用できる唯一の鍵でもあります。
|
||||
|
||||
* [マスター公開鍵を無効にする](accountset.html)。
|
||||
|
||||
* [凍結](freezes.html#no-freeze)機能を永久に放棄する。
|
||||
|
||||
* トランザクションコストが0の[Key Resetトランザクション](transaction-cost.html#key-resetトランザクション)を送信する。
|
||||
|
||||
アカウントのマスターキーペアは、マスターキーペアによるトランザクションへの署名が承認されているアカウントの`account_id`と同じ[`wallet_propose`](wallet_propose.html)応答にて生成されます。マスターキーペアは同じ応答内で生成されるため、`public_key_hex`から生成される`account_id`アカウントに[固有に関連付け](accounts.html#アドレスのエンコード)られています。
|
||||
|
||||
これは、同様に`wallet_propose` メソッドを使用して生成されても、レギュラーキーペアとしてアカウントに明示的に割り当てられる必要があるレギュラーキーペアとは対照的です。レギュラーキーペアは明示的に割り当てられるので、トランザクションの署名が承認されているアカウントの`account_id`には固有に関連付けられません。詳細は、[レギュラーキーペア](#レギュラーキーペア) を参照してください。
|
||||
|
||||
**注意:** マスターキーペアは変更できませんが、無効にできます。つまり、マスター秘密鍵が漏えいした場合、マスター秘密鍵を変更するのではなく、[無効にする](accountset.html)必要があります。
|
||||
|
||||
漏えいが発生した場合、マスターキーペアの変更は不可で、無効化するしかありませんので、マスターキーペアをオフラインで保管し、代わりにアカウントのトランザクションの署名用にレギュラーキーペアを設定することを強くお勧めします。
|
||||
|
||||
マスターキーペアをオフラインで保管する際には、不正使用者がアクセスできる場所にマスター秘密鍵を保管しないようにします。たとえば、インターネットに一切接続されない物理的に隔離されたマシンに保管したり、紙に記入して安全な場所に保管します。一般的には、インターネットと相互にやり取りをするコンピュータプログラムがアクセスできる範囲内には保管しません。マスターキーペアは、緊急時（漏えいの恐れがある場合や実際に漏えいが発生した場合にレギュラーキーペアを変更するなど）に限り、最も信頼できるデバイスでのみ使用することが理想的です。
|
||||
|
||||
|
||||
## レギュラーキーペア
|
||||
|
||||
XRP Ledgerでは、アカウントのマスターキーペアをオフラインで保管し、その後のトランザクションには _レギュラーキーペア_ と呼ばれるセカンダリキーペアで署名することができます。レギュラーキーペアの秘密鍵が漏えいした場合は、秘密鍵を削除または交換できます。その際に、アカウントの秘密鍵以外の設定を変更したり、他のアカウントとの関係を再設定する必要はありません。レギュラーキーペアを積極的にローテーションすることも可能です。（アカウントのアドレスに固有に関連付けられているアカウントのマスターキーペアでは、このような操作は実行できません。）
|
||||
|
||||
レギュラーキーペアとして使用するキーペアは、[`wallet_propose`](wallet_propose.html)メソッドを使用して生成します。ただし、サポートするアカウントの`account_id`と同時に生成され、それに固有に関連付けられている[マスターキーペア](#マスターキーペア)とは異なり、レギュラーキーペアと、このキーペアがトランザクションの署名に使用されるアカウントとの関係を明示的に作成する必要があります。レギュラーキーペアをアカウントに割り当てるには、[`SetRegularKey`](setregularkey.html)メソッドを使用します。
|
||||
|
||||
レギュラーキーペアの割り当てに関するチュートリアルについては、[レギュラーキーペアの割り当て](assign-a-regular-key-pair.html)を参照してください。
|
||||
|
||||
レギュラーキーペアを割り当てたアカウントには、次の2つのキーペアが関連付けられることになります。
|
||||
|
||||
* アカウントの`account_id`に固有に関連付けられ、オフラインで保管されるマスターキーペア。
|
||||
* アカウントに明示的に割り当てられ、アカウントのトランザクションの署名に使用されるレギュラーキーペア。
|
||||
|
||||
レギュラーキーペアをアカウントに割り当てて、[マスターキーペア](#マスターキーペア)で署名されるトランザクションを除く、すべてのトランザクションの署名にそのレギュラーキーペアを使用できます。
|
||||
|
||||
レギュラーキーペアはいつでも削除または変更できます。つまり、レギュラーキーペアの秘密鍵が漏えいした（ただしマスターキーペアの秘密鍵の漏えいは発生していない）場合、レギュラーキーペアを削除または変更するだけでアカウントの制御を取り戻すことができます。
|
||||
|
||||
レギュラーキーペアの変更または削除のチュートリアルについては、[レギュラーキーペアの割り当て](assign-a-regular-key-pair.html)を参照してください。
|
||||
|
||||
|
||||
## 署名アルゴリズム
|
||||
|
||||
暗号鍵ペアは常に特定の署名アルゴリズムに結び付けられています。署名アルゴリズムは、秘密鍵と公開鍵の間の数学的関係を定義します。暗号化署名アルゴリズムには、現在の暗号技術では、秘密鍵を使用して対応する公開鍵を「簡単に」計算できるが、公開鍵から対応する秘密鍵を計算することは実質的に不可能であるという特性があります。
|
||||
|
||||
XRP Ledgerでは次の暗号化署名アルゴリズムがサポートされています。
|
||||
|
||||
| キータイプ | アルゴリズム | 説明 |
|
||||
|-------------|-----------|---|
|
||||
| `secp256k1` | 楕円曲線[secp256k1](https://en.bitcoin.it/wiki/Secp256k1)を使用する[ECDSA](https://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm) | これはBitcoinで使用されているスキームです。XRP Ledgerではデフォルトでこのキータイプが使用されます。 |
|
||||
| `ed25519` | 楕円曲線[Ed25519](https://ed25519.cr.yp.to/)を使用する[EdDSA](https://tools.ietf.org/html/rfc8032) | パフォーマンスに優れ、その他の便利な特性を備えた新しいアルゴリズムです。Ed25519公開鍵はsecp256k1鍵よりも1バイト短いため、`rippled`ではEd25519公開鍵の先頭に`0xED`バイトが追加されます。これにより、両方の公開鍵タイプは33バイトになります。 |
|
||||
|
||||
[wallet_proposeメソッド][]を使用してキーペアを生成するときには、キーの生成に使用する暗号化署名アルゴリズムを選択するため`key_type`を指定できます。デフォルト以外のキータイプを生成した場合は、トランザクションに署名する際に`key_type`も指定する必要があります。
|
||||
|
||||
XRP Ledgerでは、サポートされているさまざまなタイプのキーペアは、マスターキーペア、レギュラーキーペア、署名者リストメンバーとして互換的に使用できます。[アドレス生成](accounts.html#アドレスのエンコード)プロセスは、secp256k1キーペアとEd25519キーペアでは同一です。
|
||||
|
||||
**注記:** 現時点では、Ed25519キーで[Payment Channelクレーム](use-payment-channels.html)に署名することはできません。これはバグです。
|
||||
|
||||
### 将来のアルゴリズム
|
||||
|
||||
今後は、暗号技術の発展に伴い、XRP Ledgerに新しい暗号化署名アルゴリズムを追加する予定です。たとえば、[Shorのアルゴリズム](https://en.wikipedia.org/wiki/Shor's_algorithm)（または類似のアルゴリズム）を使用する量子コンピューターの実用化が間近となり、楕円曲線暗号が解読される可能性が生じた場合には、Rippleは容易に解読できない暗号化署名アルゴリズムを追加できます。2018年前半の時点では、「耐量子」署名アルゴリズムはまだ実用化できる段階ではなく、量子コンピューターはさらに実現段階から遠いため、現時点では特定のアルゴリズムを追加する予定はありません。
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -0,0 +1,108 @@
|
||||
# Deposit Authorization
|
||||
|
||||
_（[DepositAuth Amendment][]が必要です。）_
|
||||
|
||||
Deposit Authorization は、XRP Ledgerの[アカウント](accounts.html)のオプション機能です。Deposit Authorizationが有効な場合、トランザクションはそのトランザクションの送信者がアカウント自体でない限り、アカウントへはどのような資産も送信できません。これには、XRPと発行済み通貨の送金が含まれます。
|
||||
|
||||
デフォルトでは、新しいアカウントではDepositAuthが無効になっています。
|
||||
|
||||
## 背景
|
||||
|
||||
金融サービスの規制やライセンスによっては、企業や組織に対して、受領するすべてのトランザクションの送信者を把握するよう義務付けています。これは、自由に生成できる偽名で参加者を識別し、デフォルトですべてのアドレスからあらゆる宛先への支払いを可能とするXRP Ledgerのような分散型システムとっては課題となります。
|
||||
|
||||
Deposit Authorizationフラグにより、XRP Ledgerを使用するユーザーが分散型レジャーの基本的な特性を変えずにこのような規制に準拠するためのオプションを採用しました。Deposit Authorizationが有効な場合、アカウントはトランザクションを送信することで明示的に承認した資金のみを受領できます。Deposit Authorizationを使用するアカウントの所有者は、アカウントに資金を入金するトランザクションを送信する _前に_ 、資金の送金元の確認に必要なデューディリジェンス（確認調査）を実施できます。
|
||||
|
||||
Deposit Authorizationを有効にすると、[Checks](known-amendments.html#checks)、[Escrow](escrow.html)、および[Payment Channel](known-amendments.html#paychan)から資金を受領できます。このような「二段階」トランザクションモデルでは、最初に送金元は資金の送金を承認するトランザクションを送信し、次に送金先は資金受領を承認するトランザクションを送信します。
|
||||
|
||||
Deposit Authorizationが有効になっている場合に[Paymentトランザクション][]から資金を受領するには、このような支払の送金元を[事前承認](#事前承認)する必要があります。_（[DepositPreauth Amendment][]が必要です。）_
|
||||
|
||||
## 推奨される使い方
|
||||
|
||||
Deposit Authorizationを最大限に活用するため、以下の実施を推奨します。
|
||||
|
||||
- XRP残高が常に最低[必要準備金](reserves.html)を上回るようにする。
|
||||
- DefaultRippleフラグをデフォルトの状態（無効）にしておく。トラストラインに対して[Rippling](rippling.html)を有効にしない。TrustSetトランザクションを送信するときには常に[`tfSetNoRipple`フラグ](trustset.html)を使用する。
|
||||
- [オファー](offercreate.html)を行わない。このようなトランザクションの実行にあたり、消費される一致オファーを事前に把握することは不可能です。
|
||||
|
||||
## 詳細なセマンティクス
|
||||
|
||||
Deposit Authorizationが有効化されているアカウントの特徴は次のとおりです。
|
||||
|
||||
- [Paymentトランザクション][]の送信先には**できません**。ただし**以下の例外**は除きます。
|
||||
- 送金先により、支払の送金元が[事前承認](#事前承認)されている場合。_（[DepositPreauth Amendment][]が必要です）_
|
||||
- アカウントのXRP残高がアカウントの最低[必要準備金](reserves.html)以下で、XRP PaymentのAmountがアカウントの最低準備金（現時点では20 XRP）以下である場合は、このアカウントを送金先に指定できます。これにより、アカウントがトランザクションを送信することも、XRPを受領することもできずに操作不可能な状態になるのを防ぎます。この場合、アカウントの所有者の準備金は関係ありません。
|
||||
- **以下に該当する場合にのみ**[PaymentChannelClaimトランザクション][]からXRPを受領できます。
|
||||
- PaymentChannelClaimトランザクションの送金元がPayment Channelの送金先である場合。
|
||||
- PaymentChannelClaimトランザクションの送金先がPaymentChannelClaimの送金元を[事前承認している](#事前承認)場合。_（[DepositPreauth Amendment][]が必要です）_
|
||||
- **以下に該当する場合にのみ**[EscrowFinishトランザクション][]からXRPを受領できます。
|
||||
- EscrowFinishトランザクションの送金元がEscrowの送金先である場合。
|
||||
- EscrowFinishトランザクションの送金先がEscrowFinishの送金元を[事前承認している](#事前承認)場合。_（[DepositPreauth Amendment][]が必要です）_
|
||||
- [CheckCash][]トランザクションを送信してXRPまたは発行済み通貨を受領**できます**。 _（[Checks Amendment][]が必要です:有効ではありません:）_
|
||||
- [OfferCreateトランザクション][]を送信してXRPまたは発行済み通貨を受領**できます**。
|
||||
- 即時には完全に実行されないOfferCreateトランザクションがアカウントから送信される場合、このアカウントは、後でオファーが他のアカウントの[Payment][]トランザクションと[OfferCreate][]トランザクションによって消費される時点で、注文済みXRPと発行済み通貨のリマインダーを受信する**ことがあります**。
|
||||
- アカウントが[NoRippleフラグ](rippling.html)を有効にせずにトラストラインを作成している場合、またはDefaultRippleフラグを有効にして通貨を発行した場合は、アカウントはRipplingの結果として、[Paymentトランザクション][]でそれらのトラストラインの発行済み通貨を受領**できます**。このようなトランザクションの送金先にすることはできません。
|
||||
- 一般的に、以下のすべての条件に該当する場合は、XRP LedgerのアカウントはXRP LedgerでXRP以外の通貨を受領**できません**。（このルールは、DepositAuthフラグに特有のものではありません。）
|
||||
- アカウントにより、ゼロ以外の限度を指定したトラストラインが作成されていない。
|
||||
- アカウントが、その他のアカウントにより作成されたトラストラインで通貨を発行していない。
|
||||
- アカウントがまだオファーを出していない。
|
||||
|
||||
以下の表に、トランザクションタイプ別にDepositAuthが有効または無効な状態での入金の可否をまとめました。
|
||||
|
||||
{% include '_snippets/depositauth-semantics-table.html' %}
|
||||
<!--{#_ #}-->
|
||||
|
||||
|
||||
## Deposit Authorizationの有効化または無効化
|
||||
|
||||
アカウントのDeposit Authorizationを有効にするには、`SetFlag`フィールドに`asfDepositAuth`の値（9）を設定した[AccountSetトランザクション][]を送信します。アカウントのDeposit Authorizationを無効にするには、`ClearFlag`フィールドに`asfDepositAuth`の値（9）を設定した[AccountSetトランザクション][]を送信します。AccountSetフラグについての詳細は、[AccountSetフラグ](accountset.html)を参照してください。
|
||||
|
||||
## AccountのDepositAuthの有効化の確認
|
||||
|
||||
アカウントのDeposit Authorizationの有効化の状態を確認するには、[account_infoメソッド][]を使用してアカウントを調べます。`Flags`フィールド（`result.account_data`オブジェクト）の値を、[AccountRootレジャーオブジェクトのビット単位フラグ](accountroot.html)と比較します。
|
||||
|
||||
`Flags`値と`lsfDepositAuth`フラグ値（0x01000000）のビット単位のANDの結果がゼロ以外の場合、アカウントではDepositAuthが有効になっています。結果がゼロの場合、アカウントではDepositAuthが無効になっています。
|
||||
|
||||
## 事前承認
|
||||
|
||||
_（[DepositPreauth Amendment][]が必要です。）_
|
||||
|
||||
DepositAuthが有効なアカウントは、特定の送金元を _事前承認_ することにより、DepositAuthが有効になっていても、これらの送金元からの支払を受領することができます。これにより、特定の送金元からの資金の直接送金が可能となり、受取人はトランザクションごとに個別にアクションを実行する必要がなくなります。事前承認はDepositAuthの使用にあたり必須の要件ではありませんが、事前承認により特定の操作を実行しやすくなります。
|
||||
|
||||
事前承認は通貨に依存しません。特定の通貨のみについてアカウントを事前承認することはできません。
|
||||
|
||||
特定の送金元を事前承認するには、`Authorize`フィールドに事前承認する別のアカウントのアドレスを指定した[DepositPreauthトランザクション][]を送信します。事前承認を取り消すには、当該アカウントのアドレスを`Unauthorize`フィールドに指定します。通常どおり、`Account`フィールドには自分自身のアドレスを指定します。現在DepositAuthを有効にしていない場合でも、アカウントを事前承認または承認解除できます。他のアカウントに設定した事前認証ステータスは保存されますが、DepositAuthを有効にしない限り、このステータスの影響はありません。アカウントがアカウント自体を事前認証することはできません。事前認証は一方向であり、反対方向の支払には影響しません。
|
||||
|
||||
別のアカウントを事前認証すると、レジャーに[DepositPreauthオブジェクト](depositpreauth-object.html)が追加されます。これにより、認証を提供するアカウントの[所有者準備金](reserves.html#所有者準備金)が増加します。アカウントで事前承認が取り消されると、オブジェクトが削除され、準備金はこれに伴い減少します。
|
||||
|
||||
DepositPreauthトランザクションの処理が完了すると、承認済みアカウントからあなたのアカウントに資金を送金できるようになります。これは、以下のトランザクションタイプのいずれかを使用してDepositAuthを有効にしている場合にも該当します。
|
||||
|
||||
- [Payment][]
|
||||
- [EscrowFinish][]
|
||||
- [PaymentChannelClaim][]
|
||||
|
||||
事前承認は、DepositAuthが有効なアカウントへのその他の送金方法には影響しません。詳しいルールについては、[詳細なセマンティクス](#詳細なセマンティクス)を参照してください。
|
||||
|
||||
### 承認の確認
|
||||
|
||||
[deposit_authorizedメソッド][]を使用して、特定のアカウントに対し別のアカウントへの入金が許可されているかどうかを確認できます。このメソッドは次の2点を確認します。
|
||||
|
||||
- 送金先アカウントがDeposit Authorizationを必要としているかどうか。（承認を必要としていない場合は、すべての送金元アカウントが承認済みとみなされます。）
|
||||
- 送金元アカウントに対し、送金先への送金が事前承認されているかどうか。
|
||||
|
||||
|
||||
## 関連項目
|
||||
|
||||
- [DepositPreauthトランザクション][]リファレンス。
|
||||
- [DepositPreauthレジャーオブジェクトタイプ](depositpreauth-object.html)。
|
||||
- [`rippled` API](rippled-api.html)の[deposit_authorizedメソッド][]。
|
||||
- [Authorized Trust Lines](authorized-trust-lines.html)機能（`RequireAuth`フラグ）により、アカウントが発行したXRP以外の通貨を保有できる取引相手が制限されます。
|
||||
- `DisallowXRP`フラグは、アカウントがXRPを受領してはならないことを示します。これはDeposit Authorizationよりもソフトな保護機能であり、XRP Ledgerにより強制されません。（クライアントアプリケーションはこのフラグに従うか、または少なくともこのフラグについて警告します。）
|
||||
- 送信トランザクションが[Destinationタグ](become-an-xrp-ledger-gateway.html#source-and-destination-tags)を指定している場合には、`RequireDest`フラグは、アカウントが通貨額のみを受領できることを示します。これにより、ユーザーが支払の目的を指定し忘れることがなくなりますが、恣意的な送金先タグを作成できる不明な送金元から受取人が保護されるわけではありません。
|
||||
- [Partial Payment](partial-payments.html)により、アカウントは不要な支払を返金できます。この際、[送金手数料](transfer-fees.html)と為替レートは送金額には追加されず、送金された金額から差し引かれます。
|
||||
<!--{# TODO: Add link to "check for authorization" tutorial DOC-1684 #}-->
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
[DepositPreauth Amendment]: known-amendments.html#depositpreauth
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -0,0 +1,35 @@
|
||||
# マルチ署名
|
||||
|
||||
マルチ署名は、複数のシークレットキーを組み合わせて使用してXRP Ledgerの[トランザクションを承認する](transaction-basics.html#取引の承認)手法です。アドレスで有効な承認手法（マルチ署名、[マスターキーペア](cryptographic-keys.html#マスターキーペア)、[レギュラーキーペア](cryptographic-keys.html#レギュラーキーペア)など）を自由に組み合わせて使用できます。（唯一の要件は、 _少なくとも1つの_ 手法を有効にする必要があることです。）
|
||||
|
||||
マルチ署名には次のメリットがあります。
|
||||
|
||||
* 複数のデバイスからのキーを要求できます。これにより、不正使用者があなたの代わりにトランザクションを送信するには複数のマシンを悪用しなければならなくなります。
|
||||
* 複数のユーザー間で1つのアドレスの管理を共有できます。この場合、各ユーザーが、そのアドレスからトランザクションを送信する際に必要な複数のキーのいずれか1つだけを所有します。
|
||||
* あなたのアドレスからトランザクションを送信できる権限を、複数ユーザーのグループに委任できます。委任を受けた各ユーザーは、あなたが通常の方法で署名できない場合にあなたのアドレスを制御できます。
|
||||
* その他のメリットもあります。
|
||||
|
||||
## 署名者リスト
|
||||
|
||||
マルチ署名を使用するには、あなたの代理として署名できるアドレスのリストを作成する必要があります。
|
||||
|
||||
[SignerListSetトランザクション][]は、あなたのアドレスからのトランザクションを承認できるアドレスを定義します。SignerListには最大8個のアドレスを指定できます。SignerListのquorum値とweight値を使用して、必要な署名の数と組み合わせを制御できます。
|
||||
|
||||
## マルチ署名済みトランザクションの送信
|
||||
|
||||
マルチ署名済みトランザクションを正常に送信するには、以下のすべての条件を満たす必要があります。
|
||||
|
||||
* トランザクションを送信するアドレス（`Account`に指定されるアドレス）は、[レジャーに`SignerList`](signerlist.html)を所有する必要があります。
|
||||
* トランザクションに`SigningPubKey`フィールドを空の文字列として含める必要があります。
|
||||
* トランザクションに、署名の配列が指定されている[`Signers`フィールド](transaction-common-fields.html#signersフィールド)を含める必要があります。
|
||||
* `Signers`配列に含まれている署名は、SignerListで定義されている署名と一致している必要があります。
|
||||
* 指定された署名で、これらの署名者に関連付けられている`weight`の合計が、SignerListの`quorum`以上である必要があります。
|
||||
* [トランザクションコスト](transaction-cost.html)（`Fee`フィールドで指定）は、通常のトランザクションコストの（N+1）倍以上である必要があります。このNは、指定される署名の数です。
|
||||
* トランザクションのすべてのフィールドは、署名収集前に定義する必要があります。フィールドの[自動入力](transaction-common-fields.html#自動入力可能なフィールド)は実行できません。
|
||||
* `Signers` 配列がバイナリ形式で指定される場合、この配列は署名者アドレスの数値に基づいて、低い値から順にソートされている必要があります。（JSONとして提出される場合は、[submit_multisignedメソッド][] がこの処理を自動的に実行します。）
|
||||
|
||||
詳細は、[マルチ署名の設定](set-up-multi-signing.html)を参照してください。
|
||||
|
||||
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
@@ -0,0 +1,52 @@
|
||||
# 準備金
|
||||
|
||||
XRP Ledgerでは、スパムや悪意のある使用によって、共有グローバル台帳（レジャー）が過度に大きくならないように、 _準備金_ の仕組みをXRPに適用しています。現在一般に市販されているのマシンで、処理中の現行レジャーを常にRAMに保存でき、全履歴がディスクに収まるように、技術の向上に合わせて台帳が大きくなるのを制限することが目的です。
|
||||
|
||||
取引（トランザクション）を送信するには、各アドレスが共有グローバル台帳内に最小量のXRPを保有している必要があります。このXRPを他のアドレスに送信することはできません。新しいアドレスに資金供給するには、必要準備金を満たすのに十分なXRPを送信する必要があります。
|
||||
|
||||
現在の最低必要準備金は**20 XRP**です。（これは、レジャーにそれ以外のオブジェクトを所有していないアドレスにかかるコストです。）
|
||||
|
||||
|
||||
## 基本準備金と所有者準備金
|
||||
|
||||
必要な準備金は2つの部分に分けられます。
|
||||
|
||||
* **基本準備金**は、レジャーの各アドレスに必要なXRPの最小額です。現在、この準備金は、20 XRP（`20000000` drop）です。
|
||||
* **所有者準備金**は、アドレスがレジャーに所有しているオブジェクトごとに必要な準備金の増加額です。現在、これは1アイテムにつき5 XRP（`5000000` drop）です。
|
||||
|
||||
|
||||
### 所有者準備金
|
||||
|
||||
レジャー内の多くのオブジェクトは特定のアドレスによって所有され、そのアドレスに対する必要準備金と見なされます。レジャーから削除されたオブジェクトは、所有者の必要準備金にカウントされなくなります。
|
||||
|
||||
- [オファー](offer.html)はそれらを発行したアドレスによって所有されています。すべてが処理済みとなるか、または資金供給のないことが判明したオファーは、取引処理によって自動的に削除されます。または、所有者は、[OfferCancelトランザクション][]を送信するか、`OfferSequence`パラメーターを含む[OfferCreateトランザクション][]を送信することで、オファーを取り消すことができます。
|
||||
- [トラストライン](ripplestate.html)は2つのアドレス間で共有されます。所有者準備金は、いずれかまたは両方のアドレスに適用されます。どちらに適用されるかは、アドレスが制御するフィールドがデフォルト状態であるかどうかによって決まります。詳細については、[Contributing to the Owner Reserve](ripplestate.html#所有者の準備金への資金供給)を参照してください。
|
||||
- [MultiSignReserve Amendment][]がない場合、1つの[SignerList](signerlist.html)は、メンバーの数に応じて、所有者準備金用に3～10個のオブジェクトとしてカウントされます。[MultiSignReserve Amendment][]が有効になっている場合、1つのSignerListは、メンバーの数に関係なく、所有者準備金用に1つのオブジェクトとしてカウントされます。関連項目: [SignerListと準備金](signerlist.html#signerlistと準備金)
|
||||
- [保留中の支払い（Escrow）](escrow-object.html)は、支払元のアドレスが所有します。
|
||||
- [Payment Channel](use-payment-channels.html)は、作成したアドレスが所有します。
|
||||
- [所有者ディレクトリー](directorynode.html)には、アドレスの所有者の準備金の対象となるすべてのレジャーオブジェクトが一覧表示されます。所有者ディレクトリー自体は準備金としてカウントされません。
|
||||
- [Checks](checks.html)は、作成したアドレス（送信先ではなく送信元）が所有します。
|
||||
|
||||
|
||||
#### 所有者準備金のエッジケース
|
||||
|
||||
XRP Ledgerでは、 [OfferCreateトランザクション][]は、資産を保持する意図の明示的なステートメントであるとみなします。オファーが実行されることで、（限界値0で、その限界値を超える残高の）トラストラインが（そのようなトラストラインが存在しない場合）`taker_pays`の通貨で自動的に作成されます。ただし、オファーの所有者が新しく作られたトラストラインの所有者準備金を満たすための十分なXRPを保持していない場合、そのオファーは資金不足とみなされます。関連項目: [オファーのライフサイクル](offers.html#オファーのライフサイクル)
|
||||
|
||||
|
||||
## 必要準備金を下回る
|
||||
|
||||
トランザクション処理中、[トランザクションコスト](transaction-cost.html)によって、送信元アドレスのXRP残高の一部が消却されます。その結果、そのアドレスのXRPが必要準備金を下回る可能性があります。
|
||||
|
||||
アドレスが保持しているXRPが、現在の必要準備金を下回ると、XRPを他のアドレスに転送するトランザクションを送信したり、自身の準備金を増やしたりできなくなります。このような場合でも、そのアドレスはレジャー内に存在し、トランザクションコストを支払うのに十分なXRPを持っている限り、その他のトランザクションを送信することができます。必要準備金を満たすために十分なXRPを受け取った場合、またはそのアドレスのXRP保有額よりも[準備金の必要額が減少した](#必要準備金の変更)場合、そのアドレスはすべてのタイプのトランザクションを再度送信できるようになります。
|
||||
|
||||
**ヒント:** アドレスが必要準備金を下回った場合は、新しい[OfferCreateトランザクション][]を送信して、追加のXRP、または既存のトラストライン上の他の通貨を入手することができます。このような取引では、新しい[トラストライン](ripplestate.html)や[レジャー内のオファーノード](offer.html)を作成することはできないため、すでにオーダーブック内にあるオファーを実行するトランザクションのみを実行することができます。
|
||||
|
||||
|
||||
## 必要準備金の変更
|
||||
|
||||
XRP Ledgerには、XRPの価値の長期的な変動に応じて必要準備金を調整する仕組みがあります。変更はすべて、コンセンサスプロセスによる承認が必要です。詳細については、[手数料の投票](fee-voting.html)を参照してください。
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
27
content/concepts/payment-system-basics/fees.ja.md
Normal file
27
content/concepts/payment-system-basics/fees.ja.md
Normal file
@@ -0,0 +1,27 @@
|
||||
# 手数料（曖昧さの回避）
|
||||
|
||||
XRP Ledgerは分散型レジャーであり、暗号技術により保護され、サーバーで構成される分散型ピアツーピアネットワークで運用されます。つまり、Rippleを含め誰もネットワークアクセス料を要求できません。
|
||||
|
||||
ただしXRP Ledgerのルールには、レジャーを悪用から保護するための中立的な手数料を含む各種手数料が設定されています。この中立的な手数料の受取先はありません。また、XRP Ledgerの内外でユーザーはさまざまな方法で相互に手数料を徴収できます。
|
||||
|
||||
|
||||
## レジャー内部
|
||||
|
||||
### 中立的な手数料
|
||||
|
||||
_**トランザクションコスト**_（トランザクション手数料とも呼ばれます）は、トランザクションの送信にあたって消却される極わずかな額のXRPです。このコストはネットワークへの負荷に比例して増減するため、ピアツーピアネットワークをスパムから保護します。詳細は、[トランザクションコスト](transaction-cost.html)を参照してください。
|
||||
|
||||
_**必要準備金**_ は、アカウントが保有する必要があるXRPの最小額です。これは、アカウントがレジャーで所有するオブジェクトの数に比例して増加します。これにより、ユーザーが不注意または悪意によってレジャーのサイズを増やすことを防ぎます。詳細は、[準備金](reserves.html)を参照してください。
|
||||
|
||||
### オプションの手数料
|
||||
|
||||
_**送金手数料**_ は、イシュアーが発行する通貨を、そのイシュアーがXRP Ledger内の他のアドレスに送金する場合に請求できる手数料であり、そのパーセンテージは任意に設定されます。詳細は、[送金手数料](transfer-fees.html)を参照してください。
|
||||
|
||||
_**トラストラインクオリティ**_ は、アカウントがトラストラインの残高を額面価格よりも高い価格または低い価格で評価できるようにする設定です。この設定により、手数料が発生するような状況になることがあります。トラストラインクオリティは、トラストラインに関連付けられていないXRPには適用されません。
|
||||
|
||||
|
||||
## レジャー外部
|
||||
|
||||
XRP Ledgerには前述の手数料しか組み込まれていませんが、この他にもレジャーに関連した手数料を請求する方法を考案することが可能です。たとえば、一般的に金融機関は、XRP Ledgerへの資金の送金やXRP Ledgerからの資金の受領に関して、手数料を顧客に請求します。
|
||||
|
||||
その他にもさまざまな手数料を設定できます。企業はクライアントアプリケーションへのアクセス、XRP Ledger以外のアカウント、取引所サービス（特にXRP Ledgerの分散型取引所内ではなくプライベートマーケットでXRPを購入する場合）、およびその他のさまざまなサービスの管理の手数料を請求できます。金融機関と取引を行う前に、必ず手数料一覧を確認してください。
|
||||
35
content/concepts/payment-system-basics/ledgers.ja.md
Normal file
35
content/concepts/payment-system-basics/ledgers.ja.md
Normal file
@@ -0,0 +1,35 @@
|
||||
# レジャー
|
||||
|
||||
XRP Ledgerは完全にオープンな共有グローバルレジャーです。個々の参加者はこのレジャーを管理する個々の機関を信頼しなくても、レジャーの整合性を信頼できます。`rippled`サーバーソフトウェアは、非常に特殊なルールによってのみ更新可能なレジャーデータベースを管理することにより、これを実現しています。各`rippled`インスタンスはレジャーの完全なコピーを保持し、`rippled`サーバーからなるピアツーピアネットワークはトランザクション候補を各サーバーに配信します。コンセンサスプロセスによって、レジャーの新しいバージョンに適用されるトランザクションが決定します。関連項目: [コンセンサスプロセス](consensus.html)。
|
||||
|
||||
|
||||
|
||||
この共有グローバルレジャーは、実際には`rippled`の内部データベースに保持されている一連の個別レジャー（レジャーバージョン）です。各レジャーバージョンには、レジャーの生成順を示す[レジャーインデックス][]が付いています。各閉鎖済みレジャーバージョンにも、レジャーの内容を示す識別用ハッシュ値があります。`rippled`インスタンスには常に、1つの処理中の「現行」オープンレジャー、コンセンサスにより承認されていないいくつかの閉鎖済みレジャー、およびコンセンサスによる検証済みの任意の数の履歴レジャーがあります。検証済みレジャーだけが、その内容が正確で変更できません。
|
||||
|
||||
1つのレジャーバージョンはさまざまな要素で構成されています:
|
||||
|
||||
|
||||
|
||||
* **ヘッダー** - [レジャーインデックス][]、レジャーのその他のコンテンツのハッシュ、その他のメタデータ。
|
||||
* **トランザクションツリー** - このレジャーの作成時に、直前のレジャーに適用された[トランザクション](transaction-formats.html)。トランザクションは、レジャーの変更を可能にする _唯一の_ 手段です。
|
||||
* **状態ツリー** - このバージョンのレジャーの設定、残高、オブジェクトを含むすべての[レジャーオブジェクト](ledger-object-types.html)。
|
||||
|
||||
|
||||
## ツリーの形式
|
||||
|
||||
レジャーの状態ツリーは、その名前のとおりツリー型データ構造です。状態ツリーの各オブジェクトは256ビットのオブジェクトIDで識別されます。JSONではレジャーオブジェクトのIDは`index`フィールドです。このフィールドには64文字の16進数文字列が含まれています（例: `"193C591BF62482468422313F9D3274B5927CA80B4DD3707E42015DD609E39C94"`）。状態ツリーの各オブジェクトには、オブジェクトの検索に使用できるIDが設定されています。各トランザクションには、トランザクションツリーでトランザクションを検索するときに使用できる識別用ハッシュが含まれています。レジャーオブジェクトの`index`（ID）と[レジャーの`ledger_index`（シーケンス番号）][レジャーインデックス]を混同しないでください。
|
||||
|
||||
**ヒント:** レジャーの状態ツリーのオブジェクトは「レジャーノード」と呼ばれることもあります。たとえばトランザクションメタデータは`AffectedNodes`のリストを返します。これをピアツーピアネットワークの「ノード」（サーバー）と混同しないでください。
|
||||
|
||||
トランザクションの場合、識別用ハッシュは署名済みトランザクションの指示に基づいていますが、検索時のトランザクションオブジェクトにはトランザクションの結果とメタデータが含まれています。これは、ハッシュの生成時には反映されません。
|
||||
|
||||
|
||||
## 関連項目
|
||||
|
||||
レジャーヘッダー、レジャーオブジェクトID、レジャーオブジェクトタイプについての詳細は、[レジャーデータフォーマット](ledger-data-formats.html)を参照してください。
|
||||
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -0,0 +1,17 @@
|
||||
# 結果のファイナリティー
|
||||
|
||||
トランザクションがコンセンサスレジャーに適用される順序は、レジャーがクローズされ、そのトランザクションセットがコンセンサスプロセスによって承認されるまで最終的なものではありません。最初に成功したトランザクションはその後で失敗する可能性があり、最初に失敗したトランザクションはその後で成功する可能性があります。さらに、あるラウンドでコンセンサスプロセスによって拒否されたトランザクションは、後のラウンドでコンセンサスに達する可能性があります。
|
||||
|
||||
検証済みレジャーには、失敗したトランザクション (`tec`結果コード）だけでなく、成功したトランザクション（`tes`結果コード）も含まれる可能性があります。それ以外の結果のトランザクションはレジャーに含まれません。
|
||||
|
||||
結果コードがそれ以外の場合は、結果が最終的なものかどうかを判断するのは困難です。次の表は、トランザクションの結果がいつ確定するかをまとめたものです。この内容は、トランザクション送信からの結果コードに基づいています。
|
||||
|
||||
| エラーコード | ファイナリティー |
|
||||
|:----------------|:-----------------------------------------------------------|
|
||||
| `tesSUCCESS` | 検証済みレジャーに含まれる場合は確定 |
|
||||
| すべての`tec`コード | 検証済みレジャーに含まれる場合は確定 |
|
||||
| すべての`tem`コード | 確定（トランザクションが有効になるようにプロトコルが変更される場合を除く） |
|
||||
| `tefPAST_SEQ` | 検証済みレジャーに同じシーケンス番号の別のトランザクションが含まれている場合は確定 |
|
||||
| `tefMAX_LEDGER` | 検証済みレジャーにトランザクションの`LastLedgerSequence`フィールドよりも大きいシーケンス番号があり、検証済みレジャーにそのトランザクションが含まれていない場合は確定 |
|
||||
|
||||
他のトランザクション結果は確定でない可能性があります。その場合、トランザクションはその後に成功または失敗する可能性があります（特に、条件の変更によってトランザクションの適用を妨げる原因がなくなった場合）。例えば、まだ存在していないアカウントにXRP以外の通貨を送信しようとしても失敗しますが、別のトランザクションで送信先アカウントを作成するのに十分なXRPを送信すれば成功します。サーバーは、一時的に失敗した署名付きのトランザクションを保存してから、事前に確認せずに後でそれを正常に適用する場合があります。
|
||||
@@ -0,0 +1,195 @@
|
||||
# 取引の基本
|
||||
|
||||
_取引（トランザクション）_ は、XRP Ledgerを変更する唯一の方法です。[コンセンサスプロセス](consensus.html)に従って署名され、送信され、検証済みのレジャーバージョンに承認された場合にのみ、トランザクションは最終的なものになります。レジャーのルールによっては、 _[疑似トランザクション](pseudo-transaction-types.html)_ も生成されます。このトランザクションは署名も送信もされませんが、コンセンサスによって承認されなければならないことは同様です。失敗したトランザクションであっても、スパム対策の[トランザクションコスト][]を支払のためXRPの残高が変わるため、レジャーに記録されます。
|
||||
|
||||
|
||||
### トランザクションの識別
|
||||
|
||||
署名付きトランザクションには、それを識別する固有の`"hash"`があります。トランザクションを送信すると、サーバーの応答でハッシュが返されます。[account_txコマンド](account_tx.html)を使用して、アカウントのトランザクション履歴でトランザクションを検索することもできます。
|
||||
|
||||
だれでも最終的なステータスを確認として[ハッシュによってトランザクションを調べる](look-up-transaction-results.html)ことができるため、トランザクションハッシュは「支払いの証明」として使用することができます。
|
||||
|
||||
|
||||
## 請求コストの正当化
|
||||
|
||||
失敗したトランザクションに対しても[トランザクションコスト](transaction-cost.html)が発生するのは不公平に思えるかもしれませんが、正当な理由から`tec`クラスのエラーが存在します。
|
||||
|
||||
* 失敗したトランザクションの後に送信するトランザクションでは、シーケンス値の番号を変更する必要はありません。失敗したトランザクションをレジャーに組み込むと、トランザクションのシーケンス番号が順に使われ予想される順序が保持されます。
|
||||
* ネットワーク全体にトランザクションを拡散されられると、ネットワークの負荷が増大します。トランザクションコストを強制することにより、攻撃者が失敗したトランザクションでネットワークを乱用することが難しくなります。
|
||||
* トランザクションコストは実際には非常に少額であるため、大量のトランザクションを送信している場合を除き、ユーザーに害を及ぼすことはありません。
|
||||
|
||||
|
||||
## 取引の承認
|
||||
|
||||
分散型XRP Ledgerでは、デジタル署名によって、トランザクションが一定のアクションを起こすが承認されていることが証明されます。署名されたトランザクションのみがネットワークに送信され、有効なレジャーに含まれます。署名付きトランザクションは不変です。その内容は変更できず、他のトランザクションでこの署名を使用することはできません。 <!-- STYLE_OVERRIDE: is authorized to -->
|
||||
|
||||
トランザクションは、次のいずれかの署名によって承認できます。
|
||||
|
||||
* 送信元アドレスと数学的に関連付けられている、マスター秘密鍵による単一の署名。[AccountSetトランザクション][]を使用して、マスターキーペアを無効または有効にできます。
|
||||
* アドレスに関連付けられているレギュラー秘密鍵と一致する単一の署名。[SetRegularKeyトランザクション][]を使用して、レギュラーキーペアを追加、削除、または置き換えることができます。
|
||||
* アドレスが所有する署名者のリストと一致する[マルチ署名](multi-signing.html)。[SignerListSetトランザクション][]を使用して、署名者のリストを追加、削除、または置換することができます。
|
||||
|
||||
署名の種類に関係なく、あらゆるタイプのトランザクションを承認できます。ただし、次の例外があります。
|
||||
|
||||
* マスター秘密鍵だけが[マスター公開鍵](accountset.html)を無効にできます。
|
||||
* マスター秘密鍵だけが[凍結機能を永続的に放棄](freezes.html#no-freeze)できます。
|
||||
* アドレスからトランザクションに署名する最後の方法を削除することはできません。
|
||||
|
||||
マスターキーとレギュラーキーペアについて詳しくは、[暗号鍵](cryptographic-keys.html)を参照してください。
|
||||
|
||||
<!--{# Add this reference after signatures concept doc is published. For more information about signatures, see [Understanding Signatures](concept-signatures.html). #}-->
|
||||
|
||||
|
||||
## トランザクションへの署名とトランザクションの送信
|
||||
|
||||
XRP Ledgerにトランザクションを送信するには、いくつかの手順を実行する必要があります。
|
||||
|
||||
1. [未署名のトランザクションをJSON形式](#未署名のトランザクションの例)で作成します。
|
||||
2. 1つ以上の署名を使用して[トランザクションを承認](#取引の承認)します。
|
||||
3. `rippled`サーバーにトランザクションを送信します。トランザクションが適切に作成されている場合、サーバーはそのトランザクションを現行バージョンのレジャーに暫定的に適用し、そのトランザクションをピアツーピアネットワークの他のメンバーに中継します。
|
||||
4. [コンセンサスプロセス](consensus.html)によって、次の検証済みレジャーに含まれる暫定的なトランザクションが決定されます。
|
||||
5. `rippled`サーバーはそれらのトランザクションを正規順序で前のレジャーに適用し、それらの結果を共有します。
|
||||
6. 十分に[信頼できるバリデータ](rippled-server-modes.html#バリデータを運用する理由) がまったく同じレジャーを作成した場合、そのレジャーは _検証済み_ であると宣言され、そのレジャーの[トランザクションの結果](transaction-results.html)は不変となります。
|
||||
|
||||
XRP決済の送信に関する対話型チュートリアルについては、[Send XRP](send-xrp.html)を参照してください。
|
||||
|
||||
|
||||
### 未署名のトランザクションの例
|
||||
|
||||
JSON形式の未署名の[Paymentトランザクション][]の例を次に示します。
|
||||
|
||||
```
|
||||
{
|
||||
"TransactionType" : "Payment",
|
||||
"Account" : "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
|
||||
"Destination" : "ra5nK24KXen9AHvsdFTKHSANinZseWnPcX",
|
||||
"Amount" : {
|
||||
"currency" : "USD",
|
||||
"value" : "1",
|
||||
"issuer" : "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn"
|
||||
},
|
||||
"Fee": "12",
|
||||
"Flags": 2147483648,
|
||||
"Sequence": 2,
|
||||
}
|
||||
```
|
||||
|
||||
XRP Ledgerは、トランザクションオブジェクトが送信元アドレス（`Account`内）フィールドによって承認されている場合にのみ、トランザクションを中継して実行します。単一の署名によってのみ承認されたトランザクションの場合、2つの選択肢があります。
|
||||
|
||||
1. バイナリーブロブに変換してオフラインで署名します。これが望ましい方法です。トランザクションの署名に使用されたアカウントの機密情報がネットワーク接続を介して送信されないことを意味するためです。
|
||||
* オフライン署名には[RippleAPI](rippleapi-reference.html#sign)を使用できます。
|
||||
2. `rippled`サーバーにトランザクションの署名を依頼します。[signコマンド](sign.html)はJSON形式のトランザクションと機密情報を受け取り、送信可能な署名付きバイナリートランザクション形式を返します。（アカウントの機密情報を送信するのは危険です。そのため、信頼できる暗号化された接続内か、またはローカル接続経由で、自分が管理しているサーバーのみに送信するようにしてください。）
|
||||
* ショートカットとして、`tx_json`オブジェクトを指定した[submitコマンド](submit.html)を使用してトランザクションへの署名とトランザクションの送信を同時に実行できます。これはテストと開発の目的の場合にのみ推奨されます。
|
||||
|
||||
## 署名付きトランザクションブロブの例
|
||||
|
||||
トランザクションに署名すると、ネットワークに送信できるバイナリーブロブが生成されます。この場合、`rippled`の[submitコマンド](submit.html)を使用します。署名付きブロブと同じトランザクションの例を示します。このトランザクションは、WebSocket APIを使用して送信されています。
|
||||
|
||||
```
|
||||
{
|
||||
"id": 2,
|
||||
"command": "submit",
|
||||
"tx_blob" : "120000240000000461D4838D7EA4C6800000000000000000000000000055534400000000004B4E9C06F24296074F7BC48F92A97916C6DC5EA968400000000000000F732103AB40A0490F9B7ED8DF29D246BF2D6269820A0EE7742ACDD457BEA7C7D0931EDB74483046022100982064CDD3F052D22788DB30B52EEA8956A32A51375E72274E417328EBA31E480221008F522C9DB4B0F31E695AA013843958A10DE8F6BA7D6759BEE645F71A7EB240BE81144B4E9C06F24296074F7BC48F92A97916C6DC5EA983143E9D4A2B8AA0780F682D136F7A56D6724EF53754"
|
||||
}
|
||||
```
|
||||
|
||||
## メタデータを含む実行済みトランザクションの例
|
||||
|
||||
トランザクションが送信されたら、APIを使用して（例えば、[txコマンド](tx.html)を使用して）トランザクションのステータスを確認できます。これにより、トランザクションの指示、その結果、およびそれを実行する過程で行われたすべての変更の[メタデータ](transaction-metadata.html) が表示されます。
|
||||
|
||||
**注意:** トランザクションが結果コード`tesSUCCESS`で**検証済み**のレジャーに表示されない限り、トランザクションの成功は最終的なものではありません。関連項目:[結果のファイナリティー](finality-of-results.html)
|
||||
|
||||
`tx`コマンドの応答の例:
|
||||
|
||||
```
|
||||
{
|
||||
"id": 6,
|
||||
"status": "success",
|
||||
"type": "response",
|
||||
"result": {
|
||||
"Account": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
|
||||
"Amount": {
|
||||
"currency": "USD",
|
||||
"issuer": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
|
||||
"value": "1"
|
||||
},
|
||||
"Destination": "ra5nK24KXen9AHvsdFTKHSANinZseWnPcX",
|
||||
"Fee": "10",
|
||||
"Flags": 2147483648,
|
||||
"Sequence": 2,
|
||||
"SigningPubKey": "03AB40A0490F9B7ED8DF29D246BF2D6269820A0EE7742ACDD457BEA7C7D0931EDB",
|
||||
"TransactionType": "Payment",
|
||||
"TxnSignature": "3045022100D64A32A506B86E880480CCB846EFA3F9665C9B11FDCA35D7124F53C486CC1D0402206EC8663308D91C928D1FDA498C3A2F8DD105211B9D90F4ECFD75172BAE733340",
|
||||
"date": 455224610,
|
||||
"hash": "33EA42FC7A06F062A7B843AF4DC7C0AB00D6644DFDF4C5D354A87C035813D321",
|
||||
"inLedger": 7013674,
|
||||
"ledger_index": 7013674,
|
||||
"meta": {
|
||||
"AffectedNodes": [
|
||||
{
|
||||
"ModifiedNode": {
|
||||
"FinalFields": {
|
||||
"Account": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
|
||||
"Balance": "99999980",
|
||||
"Flags": 0,
|
||||
"OwnerCount": 0,
|
||||
"Sequence": 3
|
||||
},
|
||||
"LedgerEntryType": "AccountRoot",
|
||||
"LedgerIndex": "13F1A95D7AAB7108D5CE7EEAF504B2894B8C674E6D68499076441C4837282BF8",
|
||||
"PreviousFields": {
|
||||
"Balance": "99999990",
|
||||
"Sequence": 2
|
||||
},
|
||||
"PreviousTxnID": "7BF105CFE4EFE78ADB63FE4E03A851440551FE189FD4B51CAAD9279C9F534F0E",
|
||||
"PreviousTxnLgrSeq": 6979192
|
||||
}
|
||||
},
|
||||
{
|
||||
"ModifiedNode": {
|
||||
"FinalFields": {
|
||||
"Balance": {
|
||||
"currency": "USD",
|
||||
"issuer": "rrrrrrrrrrrrrrrrrrrrBZbvji",
|
||||
"value": "2"
|
||||
},
|
||||
"Flags": 65536,
|
||||
"HighLimit": {
|
||||
"currency": "USD",
|
||||
"issuer": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
|
||||
"value": "0"
|
||||
},
|
||||
"HighNode": "0000000000000000",
|
||||
"LowLimit": {
|
||||
"currency": "USD",
|
||||
"issuer": "ra5nK24KXen9AHvsdFTKHSANinZseWnPcX",
|
||||
"value": "100"
|
||||
},
|
||||
"LowNode": "0000000000000000"
|
||||
},
|
||||
"LedgerEntryType": "RippleState",
|
||||
"LedgerIndex": "96D2F43BA7AE7193EC59E5E7DDB26A9D786AB1F7C580E030E7D2FF5233DA01E9",
|
||||
"PreviousFields": {
|
||||
"Balance": {
|
||||
"currency": "USD",
|
||||
"issuer": "rrrrrrrrrrrrrrrrrrrrBZbvji",
|
||||
"value": "1"
|
||||
}
|
||||
},
|
||||
"PreviousTxnID": "7BF105CFE4EFE78ADB63FE4E03A851440551FE189FD4B51CAAD9279C9F534F0E",
|
||||
"PreviousTxnLgrSeq": 6979192
|
||||
}
|
||||
}
|
||||
],
|
||||
"TransactionIndex": 0,
|
||||
"TransactionResult": "tesSUCCESS"
|
||||
},
|
||||
"validated": true
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -0,0 +1,157 @@
|
||||
# トランザクションコスト
|
||||
|
||||
XRP LedgerをスパムやDoS攻撃から守るため、各トランザクションでは少額の[XRP](https://ripple.com/xrp-portal/)が消却されます。この _トランザクションコスト_ はネットワークの負荷とともに増加するように設計されており、故意または不注意にネットワークに過剰な負荷をかけると非常に高くつきます。
|
||||
|
||||
各トランザクションのトランザクションコストを支払う際には、[消却するXRPの額を指定](#トランザクションコストの指定)する必要があります。
|
||||
|
||||
|
||||
## 現在のトランザクションコスト
|
||||
|
||||
ネットワークが標準のトランザクションに必要とする現在の最低トランザクションコストは**0.00001 XRP**（10 drop）です。これは負荷が通常より高くなると増加することがあります。
|
||||
|
||||
また、[現在のトランザクションコストについて`rippled`に問い合わせる](#トランザクションコストの問い合わせ)こともできます。
|
||||
|
||||
### 特別なトランザクションコスト
|
||||
|
||||
一部のトランザクションには異なるトランザクションコストがあります。
|
||||
|
||||
| トランザクション | 負荷スケーリング前のコスト |
|
||||
|-----------------------|--------------------------|
|
||||
| [Referenceトランザクション](#referenceトランザクションコスト)（ほとんどのトランザクション） | 10 drop |
|
||||
| [Key Resetトランザクション](#key-resetトランザクション) | 0 |
|
||||
| [マルチ署名済みトランザクション](multi-signing.html) | 10 drop × （1 + 署名の数） |
|
||||
| [フルフィルメントを伴うEscrowFinishトランザクション](escrowfinish.html) | 10 drop × （33 + （バイト単位のフルフィルメントサイズ ÷ 16）） |
|
||||
|
||||
|
||||
## トランザクションコストの受取人
|
||||
|
||||
トランザクションコストは誰かに支払われるものではありません。XRPは取り消し不能で消却されます。XRPを新たに作ることはできないため、XRPの希少性が高まり、XRPの価値を高めることによって、すべてのXRP保有者に利益がもたらされます。
|
||||
|
||||
|
||||
## 負荷コストとオープンレジャーコスト
|
||||
|
||||
[FeeEscalation Amendment][]が有効な場合、トランザクションコストには以下の2つのしきい値があります。
|
||||
|
||||
* トランザクションコストが`rippled`サーバーの[負荷ベーストランザクションコストのしきい値](#ローカル負荷コスト)を満たしていない場合、サーバーはそのトランザクションを完全に無視します。（このロジックはAmendmentの有無にかかわらず基本的に変わりません。）
|
||||
* トランザクションコストが`rippled`サーバーの[オープンレジャーコストのしきい値](#オープンレジャーコスト)を満たしていない場合、サーバーはそのトランザクションを後のレジャーのキューに入れます。
|
||||
|
||||
これによってトランザクションは大まかに以下の3つのカテゴリーに分けられます。
|
||||
|
||||
* トランザクションコストが低く設定され、負荷ベーストランザクションコストによって拒否されるトランザクション。
|
||||
* トランザクションコストが高く設定され、現在のオープンレジャーに組み入れられるトランザクション。
|
||||
* その中間のトランザクション。[後のレジャーバージョンのキューに入れられます](#キューに入れられたトランザクション)。
|
||||
|
||||
|
||||
## ローカル負荷コスト
|
||||
|
||||
各`rippled`サーバーには、現在の負荷に基づいてコストしきい値が保持されています。送信するトランザクションの`Fee`値が`rippled`サーバーの現在の負荷ベーストランザクションコストより低い場合、そのサーバーはトランザクションの適用も中継もしません。（**注記:** [管理者接続](get-started-with-the-rippled-api.html)を介してトランザクションを送信する場合、トランザクションがスケーリングされていない最低トランザクションコストを満たすかぎり、サーバーはそのトランザクションを適用し、中継します。）トランザクションの`Fee`値が大半のサーバーの要件を満たさないかぎり、そのトランザクションが[コンセンサスプロセス](https://ripple.com/build/ripple-ledger-consensus-process/)を完了する可能性は極めて低くなります。
|
||||
|
||||
## オープンレジャーコスト
|
||||
|
||||
`rippled`サーバーにはトランザクションコストを強制する2つ目のメカニズムがあり、 _オープンレジャーコスト_ と呼ばれます。トランザクションがXRPによるオープンレジャーコスト要件を満たす場合のみ、そのトランザクションをオープンレジャーに含めることができます。オープンレジャーコスト要件を満たさないトランザクションは、[次のレジャーのキューに入れられます](#キューに入れられたトランザクション)。
|
||||
|
||||
新しいレジャーバージョンごとに、サーバーは前のレジャーのトランザクション数に基づいてオープンレジャーに含めるトランザクション数のソフトリミットを選択します。オープンレジャーコストは、オープンレジャー内のトランザクション数がソフトリミットと等しくなるまでは、スケーリングされていない最低トランザクションコストと同じです。それを超えると、オープンレジャーコストはオープンレジャーに含まれるトランザクションごとに急激に増加します。次のレジャーでは、現行のレジャーにソフトリミットを超えるトランザクションが含まれていれば、サーバーはソフトリミットを高くし、コンセンサスプロセスに5秒より時間が掛かる場合はソフトリミットを低くします。
|
||||
|
||||
オープンレジャーコストの水準は、絶対的なトランザクションコストではなく[標準的なトランザクションコストに比例](#手数料レベル)しています。標準よりも高い要件を持つトランザクションタイプ（[マルチ署名済みトランザクション](multi-signing.html)など）は、オープンレジャーコストを満たすために最低限のトランザクションコスト要件を持つトランザクションよりも多く支払う必要があります。
|
||||
|
||||
関連項目: [`rippled`リポジトリー内のFee Escalationの説明](https://github.com/ripple/rippled/blob/release/src/ripple/app/misc/FeeEscalation.md)。
|
||||
|
||||
### キューに入れられたトランザクション
|
||||
|
||||
`rippled`が、サーバーのローカル負荷コストは満たすが[オープンレジャーコスト](#オープンレジャーコスト)は満たさないトランザクションを受け取った場合、サーバーはそのトランザクションが後のレジャーに「含まれる可能性」を判断します。その可能性が高いと判断すれば、サーバーはそのトランザクションをトランザクションキューに追加し、他のネットワークメンバーにトランザクションを中継します。そうでない場合、サーバーはトランザクションを破棄します。[トランザクションコストは検証済みレジャーに含まれるトランザクションにのみ適用される](#トランザクションコストと失敗したトランザクション)ため、サーバーは、トランザクションコストを支払わないトランザクションにより生じるネットワーク負荷量を最低限に抑えようとします。
|
||||
|
||||
キューに入れられたトランザクションの詳細は、[トランザクションキュー](transaction-queue.html)を参照してください。
|
||||
|
||||
## Referenceトランザクションコスト
|
||||
|
||||
「Referenceトランザクション」とは、負荷スケーリング前の[トランザクションコスト](transaction-cost.html)という観点からは、最も安価な（無料ではない）トランザクションと言えます。ほとんどのトランザクションのコストはReferenceトランザクションと同じです。[マルチ署名済みトランザクション](multi-signing.html)など一部のトランザクションでは、このコストの数倍のコストが必要です。オープンレジャーコストが上昇する場合は、コスト水準はトランザクションの基本コストに比例します。
|
||||
|
||||
### 手数料レベル
|
||||
|
||||
_手数料レベル_ は、トランザクションの最少コストと実際のコストとの相対的な差を表します。[オープンレジャーコスト](#オープンレジャーコスト)は絶対的なコストではなく手数料レベルで評価されます。比較する場合は以下の表を参照してください。
|
||||
|
||||
| トランザクション | drop単位の最少コスト | 手数料レベルでの最少コスト | drop単位で倍のコスト | 手数料レベルで倍のコスト |
|
||||
|-------------|-----------------------|----------------------------|----------------------|---------------------------|
|
||||
| Referenceトランザクション（ほとんどのトランザクション） | 10 | 256 | 20 | 512 |
|
||||
| 4つの署名を持つ[マルチ署名済みトランザクション](multi-signing.html) | 50 | 256 | 100 | 512 |
|
||||
| [Key Resetトランザクション](transaction-cost.html#key-resetトランザクション) | 0 | （事実上無限） | なし | （事実上無限） |
|
||||
| 32バイトのプリイメージ付きの[EscrowFinishトランザクション](escrowfinish.html)。 | 350 | 256 | 700 | 512 |
|
||||
|
||||
|
||||
## トランザクションコストの問い合わせ
|
||||
|
||||
`rippled` APIには、ローカル負荷ベースのトランザクションコストを問い合わせる方法が2つあります。`server_info`コマンド（人を対象とする）と`server_state`コマンド（マシンを対象とする）です。
|
||||
|
||||
[FeeEscalation Amendment][]が有効である場合、[feeメソッド][]を使用してオープンレジャーコストを確認することができます。
|
||||
|
||||
### server_info
|
||||
|
||||
[server_infoメソッド][]は、`validated_ledger.base_fee_xrp`と同様に、前のレジャー時点のスケーリングされていない最低XRPコストを10進XRPの形式でレポートします。トランザクションを中継するために必要な実際のコストをスケーリングするには、その`base_fee_xrp`値に同じ応答内の`load_factor`パラメーターを掛けます。このパラメーターは、サーバーの現在の負荷レベルを表します。つまり、次の式になります。
|
||||
|
||||
**XRP単位の現在のトランザクションコスト = `base_fee_xrp` × `load_factor`**
|
||||
|
||||
|
||||
### server_state
|
||||
|
||||
[server_stateメソッド][]は、`rippled`の内部負荷計算の内容をそのままの表示形式で返します。この場合、有効負荷率は`load_base`に対する`load_factor` の割合です。`validated_ledger.base_fee`パラメーターは、[XRPのdrop](basic-data-types.html#通貨額の指定)単位の最低トランザクションコストをレポートします。この設計により、`rippled`では整数のみでトランザクションコストの計算ができ、サーバー負荷の微調整も十分に行えます。実際のトランザクションコストの計算は以下のようになります。
|
||||
|
||||
**drop単位の現在のトランザクションコスト = (`base_fee` × `load_factor`) ÷ `load_base`**
|
||||
|
||||
|
||||
|
||||
## トランザクションコストの指定
|
||||
|
||||
署名されたすべてのトランザクションの[`Fee`フィールド](transaction-common-fields.html)には、トランザクションコストを含める必要があります。署名されたトランザクションのすべてのフィールドと同様に、このフィールドは署名の無効化を行わなければ変更できません。
|
||||
|
||||
通常、XRP Ledgerはトランザクションを署名された _とおりに_ 実行します。（少なくとも、分散型コンセンサスネットワーク全体をコーディネートしてそれ以外のことを実行するのは難しいと思われます。）したがって、`Fee`フィールドに指定されたXRPの額が、ネットワーク内で指定されているどの現在の最低トランザクションコストをもはるかに上回っていたとしても、指定したとおりのXRPがすべてのトランザクションで消却されます。トランザクションコストでは、アカウントの[準備金](reserves.html)用に確保していたXRPも消却される場合があります。
|
||||
|
||||
トランザクションに署名する前に、[現在の負荷ベースのトランザクションコストを調べる](#トランザクションコストの問い合わせ)ことをお勧めします。負荷スケーリングが原因でトランザクションコストが高い場合は、低下するまで待つことができます。トランザクションをすぐに送信するつもりがない場合は、トランザクションコストにおける将来の負荷ベースの変動を考慮して、少し高めのトランザクションコストを指定することをお勧めします。
|
||||
|
||||
|
||||
### トランザクションコストの自動指定
|
||||
|
||||
オンラインでトランザクションに署名する場合は、`Fee`フィールドを省略できます。この場合、`rippled`または[RippleAPI](rippleapi-reference.html)が現在の要件に照らしてピアツーピアネットワークの状態を確認し、トランザクションに署名する前に`Fee`値を追加します。ただし、このようなトランザクションコストへの自動入力にはいくつかの欠点と制限事項があります。
|
||||
|
||||
* トランザクションに署名し、分散するまでの間にネットワークのトランザクションコストが上昇した場合、そのトランザクションは承認されない場合があります。
|
||||
* 最悪の場合、トランザクションに`LastLedgerSequence`パラメーターが含まれているか、同じ`Sequence`番号を使用する新しいトランザクションによってそのトランザクションがキャンセルされない限り、トランザクションは明確に承認も拒否もされない状態のままとなってしまいます。ベストプラクティスについては、[信頼できるトランザクションの送信](reliable-transaction-submission.html)を参照してください。
|
||||
* 署名するトランザクションの`Fee`フィールドの正確な値は事前にわかりません。
|
||||
* `rippled`を使用している場合は、[signメソッド][]の`fee_mult_max`パラメーターと`fee_div_max`パラメーターを使用して、署名しようとしている負荷スケーリングに制限を設定することもできます。
|
||||
* オフラインのマシンから現在のトランザクションコストを調べることはできません。
|
||||
* [マルチ署名](multi-signing.html)の場合、トランザクションコストの自動指定は行えません。
|
||||
|
||||
|
||||
|
||||
## トランザクションコストと失敗したトランザクション
|
||||
|
||||
トランザクションコストの目的はXRP Ledgerピアツーピアネットワークを過度な負荷から保護することであるため、トランザクションが成功するかどうかにかかわらず、ネットワークに分散されるすべてのトランザクションにコストが適用されます。ただし、共有のグローバルレジャーに作用するため、トランザクションを検証済みレジャーに含める必要があります。したがって、`rippled`サーバーは[`tec`ステータスコード](transaction-results.html)（「tec」は「トランザクションエンジン - 請求手数料のみ」（Transaction Engine - Claimed fee only）を表します）で、失敗したトランザクションをレジャーに含めようとします。
|
||||
|
||||
トランザクションコストは、トランザクションが実際に検証済みレジャーに含められた場合に、送信者のXRP残高から差し引かれるだけです。このことは、トランザクションが成功するか`tec`コードとともに失敗するかにかかわらず適用されます。
|
||||
|
||||
トランザクションの失敗が[確定](finality-of-results.html)である場合、`rippled`サーバーによるネットワークへの中継は行われません。トランザクションは検証済みレジャーに含まれないため、誰のXRP残高にも影響することはありません。
|
||||
|
||||
### 不十分なXRP
|
||||
|
||||
`rippled`サーバーが最初にトランザクションを評価するとき、送信側アカウントにXRPトランザクションコストを支払うのに十分なXRP残高がない場合は、エラーコード`terINSUF_FEE_B`にてトランザクションを拒否します。これは`ter`（再試行）コードであるため、トランザクションの結果が[確定](finality-of-results.html)になるまで、`rippled`サーバーはネットワークへの中継を行わずにトランザクションを再試行します。
|
||||
|
||||
トランザクションはすでにネットワークに配信されているけれども、アカウントにトランザクションコストを支払うのに十分なXRPがない場合は、結果コード`tecINSUFF_FEE`が発生します。この場合、アカウントからは可能なかぎりすべてのXRPが支払われるため、最終的に0 XRPになります。これは、`rippled` がトランザクションをネットワークに中継するかどうかを進行中のレジャーに基づいて判断するために起こります。しかしコンセンサスレジャーを作成するときにトランザクションは破棄されるか並べ替えられることになります。
|
||||
|
||||
|
||||
## Key Resetトランザクション
|
||||
|
||||
特殊なケースですが、アカウントの[lsfPasswordSpentフラグ](accountroot.html)が無効であるかぎり、そのアカウントはトランザクションコスト`0`で[SetRegularKey](setregularkey.html)トランザクションを送信できます。このトランザクションにはアカウントの _マスターキーペア_ による署名が必要です。このトランザクションを送信すると、lsfPasswordSpentフラグが有効になります。
|
||||
|
||||
この機能は、レギュラーキーが危害を受けた場合に、危害を受けたアカウントに使用可能なXRPがあるかどうかを気にすることなく、そのアカウントを復元できるように設計されています。このようにして、追加のXRPを送信する前にそのアカウントを再び管理できるようになります。
|
||||
|
||||
[lsfPasswordSpentフラグ](accountroot.html)は無効になります。このフラグを有効にするには、マスターキーペアによって署名されたSetRegularKeyトランザクションを送信します。アカウントでXRPの[支払い](payment.html)が受け入れた場合、再び無効になります。
|
||||
|
||||
[FeeEscalation Amendment][]が有効な場合、Key Resetトランザクションの名目トランザクションコストがゼロであっても、`rippled`は他のトランザクションよりもKey Resetトランザクションを優先します。
|
||||
|
||||
|
||||
## トランザクションコストの変更
|
||||
|
||||
XRP Ledgerは、XRPの価値が長期的に変化することを見越して、最低トランザクションコストを変更するしくみを備えています。変更はすべて、コンセンサスプロセスによる承認が必要です。詳細は、[手数料の投票](fee-voting.html)を参照してください。
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
111
content/concepts/payment-types/checks.ja.md
Normal file
111
content/concepts/payment-types/checks.ja.md
Normal file
@@ -0,0 +1,111 @@
|
||||
# Checks
|
||||
|
||||
_（[Checks Amendment][]が必要です :not_enabled:）_
|
||||
|
||||
XRP LedgerのChecks機能を使用すると、指定の受取人による取消または換金が可能な後払いの支払いを生成することができます。個人用の紙の小切手と同様に、XRP Ledger Checksでは最初に資金の送金元が金額と受取人を指定するCheckを作成します。受取人はCheckを換金して、送金元のアカウントから受取人のアカウントに資金を移動します。受取人がCheckを換金するまでは、実際の資金移動は発生しません。Checkの作成時には資金は保留されていないことから、受取人が換金する時点で送金元に十分な資金がない場合、従来の小切手同様に換金が失敗します。Checkを換金できなかった場合、送信者はCheckが有効期限切れになるまで再試行できます。
|
||||
|
||||
XRP Ledger Checksには有効期限があり、この期限を過ぎると換金できなくなります。受取人が有効期限までにCheckを換金できなかった場合、Checkオブジェクトは誰かに取り消されるまでXRP Ledgerに残ります。有効期限切れになったCheckは誰でも取り消すことができます。有効期限前、あるいはChecksが換金されるまでは、送金元と受取人のみがCheckを取り消すことができます。Checkオブジェクトは、送金元がそのCheckを換金できた時点または誰かが取り消した時点でLedgerから削除されます。
|
||||
|
||||
Checksは[Escrow](escrow.html)と[Payment Channel](use-payment-channels.html)に似ていますが、Checksとこれらの機能の間には重要な相違がいくつかあります。
|
||||
|
||||
* Checksでは発行済み通貨を送金できます。Payment ChannelとEscrowで送金できるのはXRPのみです。
|
||||
|
||||
* Checksは資金を凍結しません。Payment ChannelとEscrowでは、送金元が発行したクレームでXRPが清算されるか（Payment Channel）、または有効期限切れまたはCrypto-conditionsによってXRPがリリースされる（Escrow）までは、そのXRPを使用できません。
|
||||
|
||||
* EscrowではXRPを自分自身に送金できます。ChecksとPayment Channelを使用してXRP（Checksの場合は発行済み通貨）を自身に送金することはできません。
|
||||
|
||||
|
||||
**注記:** [Checks Amendment][]:not_enabled: により、[OfferCreate][]トランザクションの有効期限が変更されます。詳細は[オファーの有効期限](offers.html#オファーの有効期限)を参照してください。
|
||||
|
||||
|
||||
## Checksを利用する理由
|
||||
|
||||
従来の紙の小切手では、実際の通貨を即座にやり取りすることなく残高を送金できます。XRP Ledger Checksを使用すると、銀行業界でよく利用され受け入れられている方法で資金を非同期にやり取りすることができます。
|
||||
|
||||
XRP Ledger Checksは、XRP Ledgerに固有の問題も解決できます。たとえば、ユーザーが不審な支払いを拒否したり、支払いの一部のみを受領することを可能にします。これは、コンプライアンス上の理由から支払いの受け入れに慎重に対応する必要がある機関にとっては有用です。
|
||||
|
||||
Checksはその他のさまざまな用途に利用できる可能性があります。RippleはコミュニティにてChecksの新しく創造的な用途が探られていくことを推奨しています。
|
||||
|
||||
|
||||
### ユースケース: 支払いの承認
|
||||
|
||||
**課題:** [BSA、KYC、AML、CFT](become-an-xrp-ledger-gateway.html#gateway-compliance)などの規制に準拠するにあたり、金融機関は受領する資金の送金元に関する文書を提出する必要があります。違法な資金移動を防止するため、これらの規制は金融機関に対して、処理済のすべての支払いについて、その送金元と送金先を開示するよう義務付けています。XRP Ledgerの性質上、誰でもXRPを（および該当する場合には発行済み通貨を）XRP Ledger上の金融機関のアカウントに送金することができます。金融機関のコンプライアンス部門では、このような不審な支払いへの対応にかかるコスト（罰金の可能性を含む）の増大と処理の遅れが生じます。
|
||||
|
||||
**解決策:** 金融機関は各自のXRP Ledgerのアカウントで、[`AccountSet`トランザクションの`asfDepositAuth`フラグを設定](accountset.html)することにより、[Deposit Authorization](depositauth.html)を有効にできます。これにより、アカウントはPaymentトランザクションを受領できなくなります。Deposit Authorizationが有効なアカウントは、Escrow、Payment Channel、またはChecksでのみ資金を受領できます。Deposit Authorizationが有効な場合、Checksが最もシンプルで使いやすく、柔軟な資金移動手段となります。
|
||||
|
||||
|
||||
## 使用法
|
||||
|
||||
Checksの一般的なライフサイクルを以下で説明します。
|
||||
|
||||
<!--{# Diagram source: https://docs.google.com/drawings/d/1Ez8OZVB2TLH-b_kSFOAgfYqXlEQt4KaUBW6F3TJAv_Q/edit #}-->
|
||||
|
||||
[](img/checks-happy-path.ja.png)
|
||||
|
||||
**ステップ1:** Checkを作成するため、送金元が[CheckCreate][]トランザクションを送信し、受取人（`Destination`）、有効期限（`Expiration`）、および送金元アカウントからの引き落とし限度額（`SendMax`）を指定します。
|
||||
|
||||
|
||||
**ステップ2:** CheckCreateトランザクションの処理が完了すると、XRP Ledgerに[Checkオブジェクト](check.html)が作成されます。このオブジェクトには、オブジェクトを作成したトランザクションにより定義されたCheckのプロパティーが含まれています。有効期限前にこのオブジェクトを変更できるのは、送金元（[CheckCancel][]トランザクションで取り消す）と受取人（取り消すかまたは換金する）だけです。有効期限の経過後は、誰でもCheckを取り消すことができます。
|
||||
|
||||
**ステップ3:** Checkを換金するため、受取人が[CheckCash][]トランザクションを送信します。受取人には次の2つのCheck換金オプションがあります。
|
||||
|
||||
* `Amount` — 受取人はこのオプションを使用して換金する正確な額を指定できます。これは、送金元が想定される[送金手数料](transfer-fees.html)をCheckの額に上乗せし、受取人は請求書やその他の契約に記載されている指定された額のみ受け取れるようにする場合に役立ちます。
|
||||
|
||||
* `DeliverMin` — 受取人はこのオプションを使用してCheckから受領する最小額を指定できます。受取人がこのオプションを使用する場合、`rippled`は可能な限り多くの送金を試み、少なくともこの額以上を送金します。受取人に入金できる額がこの額よりも少ない場合には、このトランザクションは失敗します。
|
||||
|
||||
送金元にCheckの裏付けとなる資金が十分あり、有効期限が経過してなければ、資金は送金元のアカウントから引き落とされ、受取人のアカウントに入金され、Checkオブジェクトは消却されます。
|
||||
|
||||
|
||||
|
||||
#### 有効期限切れの例
|
||||
|
||||
Checksが有効期限切れになった場合のライフサイクルを以下で説明します。
|
||||
|
||||
<!--{# Diagram source: https://docs.google.com/drawings/d/11auqa0kVUPonqlc_RaQUfHcSkUI47xneSKpwlLxzSK0/edit #}-->
|
||||
|
||||
[](img/checks-expiration.ja.png)
|
||||
|
||||
|
||||
Checksはすべて同じ方法で開始されるため、**ステップ1と2**は換金の例と同じです。
|
||||
|
||||
**ステップ3a:** 受取人が換金する前にCheckが有効期限切れになると、そのCheckは換金できなくなりますが、レジャーに残ります。
|
||||
|
||||
**ステップ4a:** 有効期限切れになったCheckは、[CheckCancel][]トランザクションを送信することで誰でも取り消すことができます。このトランザクションによりレジャーからCheckが削除されます。
|
||||
|
||||
|
||||
|
||||
## Checksの利用可能性
|
||||
|
||||
Checksを使用するには`rippled` v0.90.0以降が必要です。2018年10月11日の時点では、Checks Amendmentは本番環境のXRP Ledgerで有効になっていません。すべての既知のAmendmentの最新状況については、[既知のAmendment](known-amendments.html)を参照してください。Amendmentを有効化し、Amendmentに投票する方法については、[Amendmentプロセス](amendments.html#amendmentプロセス)を参照してください。
|
||||
|
||||
Test NetまたはプライベートXRP LedgerネットワークでのAmendmentの状況を確認するには、[featureメソッド][]を使用してください。
|
||||
|
||||
|
||||
## 参考情報
|
||||
|
||||
XRP LedgerのChecksの詳細は、以下を参照してください。
|
||||
|
||||
- [トランザクションのリファレンス](transaction-types.html)
|
||||
- [CheckCreate][]
|
||||
- [CheckCash][]
|
||||
- [CheckCancel][]
|
||||
- [Checksのチュートリアル](use-checks.html)
|
||||
- [Checkの送信](send-a-check.html)
|
||||
- [送金元アドレスに基づくChecksの検索](look-up-checks-by-sender.html)
|
||||
- [受取人アドレスに基づくChecksの検索](look-up-checks-by-recipient.html)
|
||||
- [Checkの指定された金額での換金](cash-a-check-for-an-exact-amount.html)
|
||||
- [Checkの変動金額での換金](cash-a-check-for-a-flexible-amount.html)
|
||||
- [Checkの取消し](cancel-a-check.html)
|
||||
- [Checks Amendment][]
|
||||
|
||||
関連機能の詳細については、以下を参照してください。
|
||||
|
||||
* [Deposit Authorization](depositauth.html)
|
||||
* [Escrow](escrow.html)
|
||||
* [Payment Channelチュートリアル](use-payment-channels.html)
|
||||
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
25
content/concepts/payment-types/cross-currency-payments.ja.md
Normal file
25
content/concepts/payment-types/cross-currency-payments.ja.md
Normal file
@@ -0,0 +1,25 @@
|
||||
# 複数通貨間の支払い
|
||||
|
||||
XRP Ledgerでは、1つ以上の発行済み通貨、XRP、またはその両方を交換して、複数通貨間で支払いを送金できます。[XRPによる直接支払](use-simple-xrp-payments.html)と同様に、このような支払いでは[Paymentトランザクションタイプ][Payment]が使用されます。XRP Ledgerでの複数通貨間の支払いは完全に非可分です。つまり、支払いを全額実行するか、またはまったく実行しないかのいずれかになります。
|
||||
|
||||
デフォルトでは、複数通貨間の支払いでは宛先に一定額が送金され、支払元が変動コストを負担します。複数通貨間の支払いが、[Partial Payments](partial-payments.html)で行われ、一定の送金限度内の変動額が宛先に送金される場合もあります。
|
||||
|
||||
|
||||
## 前提条件
|
||||
|
||||
- 定義上、複数通貨間支払いには2種類以上の通貨が関係します。つまり、関係する通貨のうち、少なくとも1種類以上がXRP以外の発行済み通貨である必要があります。
|
||||
- 通常は、[XRP Ledgerゲートウェイ](become-an-xrp-ledger-gateway.html)が発行した通貨を1種類以上使用することになります。このような通貨はXRP Ledger外部の資金を担保とし、ゲートウェイを通じて引き出すことができます。
|
||||
- 取引を行う当事者が、XRP Ledger内でのみ発行され、外部の担保がないデジタルトークンを送受信し、何らかの価値を持つ資産として取り扱うことを望む限り、このデジタルトークンを使用することもできます。
|
||||
- 送金元と受取人の間に1つ以上の[パス](paths.html)が確立しており、すべてのパスの総流動性が、支払いを促進するのに十分である必要があります。複数通貨間の支払いの場合、これは一般に通貨取引[オファー](offers.html)を消費することを意味します。
|
||||
|
||||
|
||||
## オートブリッジング
|
||||
|
||||
2種類の発行済み通貨を自動的に交換する複数通貨間の支払いでは、XRPの使用により支払いコストを抑えられる場合には自動的にXRPが使用されます。この場合、オーダーブックを接続して流動性プールが拡大されます。たとえば、USDからMXNに送金する支払いの場合、USDからXRP、XRPからMXNへの交換にかかるコストが、USDからMXNへの直接交換にかかるコストよりも低い場合には、前者の交換が自動的に実行されます。
|
||||
|
||||
詳細は、[オートブリッジング](autobridging.html)を参照してください。
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
141
content/concepts/payment-types/escrow.ja.md
Normal file
141
content/concepts/payment-types/escrow.ja.md
Normal file
@@ -0,0 +1,141 @@
|
||||
# Escrow
|
||||
|
||||
Escrowは、XRP建ての条件付き送金決済を可能にするXRP Ledgerの機能です。 _Escrow_ と呼ばれるこの条件付き決済では、XRPはエスクローに預託され、後日特定の条件が満たされた時点で送金されます。Escrowを完了する条件には、時間ベースのロック解除や[Crypto-conditions][]などがあります。期限までに終了しなかった場合に期限切れとなるようにEscrowを設定することもできます。
|
||||
|
||||
エスクローに預託されているXRPはロックアップされます。Escrowが正常に終了またはキャンセルされるまでは、誰もXRPを使用または消却できません。有効期限前は、指定された受取人のみがXRPを受領できます。有効期限経過後は、XRPは送金元にのみ返金されます。
|
||||
|
||||
## 使用法
|
||||
|
||||
<!--{# Diagram sources: https://docs.google.com/presentation/d/1C-_TLkkoQEH7KJ6Gjwa1gO6EX17SLiJ8lxvFcAl6Rxo/ #}-->
|
||||
|
||||
[](img/escrow-success-flow.ja.png)
|
||||
|
||||
**ステップ1:** Escrowを送信するにあたり、送金元は[EscrowCreateトランザクション][]を使用していくらかのXRPをロックアップします。このトランザクションでは、終了時刻または有効期限、あるいはその両方が定義されます。また、このトランザクションでは、Escrow終了時に満たされるべきCrypto-conditionも定義できます。さらに、このトランザクションでは、XRPの指定受取人を定義する必要があります。受取人と送金元は同じでも _かまいません_ 。
|
||||
|
||||
**ステップ2:** このトランザクションの処理完了後に、エスクローに預託されたXRPを保持する[Escrowオブジェクト](escrow-object.html)がXRP Ledgerに作成されます。このオブジェクトには、オブジェクトを作成したトランザクションにより定義されたEscrowのプロパティーが含まれています。このEscrowに終了時刻が設定されている場合、この時刻まではXRPには誰もアクセスできません。
|
||||
|
||||
**ステップ3:** 受取人またはその他のXRP Ledgerアドレスが[EscrowFinishトランザクション][]を送信し、XRPが送金されます。正しい条件が満たされると、レジャーのEscrowオブジェクトは消却され、XRPが指定受取人に入金されます。EscrowにCrypto-conditionが指定されている場合、このトランザクションにはその条件に対するフルフィルメントが含まれている必要があります。Escrowの有効期限がすでに切れている場合、EscrowFinishトランザクションはコード[`tecNO_PERMISSION`](tec-codes.html)で失敗します。
|
||||
|
||||
### 有効期限切れの例
|
||||
|
||||
[](img/escrow-cancel-flow.ja.png)
|
||||
|
||||
Escrowはすべて同じ方法で開始されるため、**ステップ1と2**は正常終了の例と同じです。
|
||||
|
||||
**ステップ3a:** Escrowに有効期限が設定されており、有効期限までにEscrowが正常に終了しなかった場合、Escrowは期限切れとみなされます。XRP Ledgerに引き続き残りますが、これ以降は正常に終了できなくなります。（期限切れオブジェクトは、トランザクションにより変更されるまでレジャーに残ります。時間ベースのトリガーではレジャーの内容は変更できません。）
|
||||
|
||||
**ステップ4a:** 送金元またはその他のXRP Ledgerアドレスが、[EscrowCancelトランザクション][]を送信し、期限切れのEscrowをキャンセルします。これによりレジャーの[Escrowオブジェクト](escrow-object.html)が消却され、XRPは送金元に返金されます。
|
||||
|
||||
## 制約事項
|
||||
|
||||
Escrowは、XRP Ledgerを[Interledger Protocol][]やその他のスマートコントラクトで使用できるようにする機能として設計されています。現行バージョンでは、複雑にならないように範囲が適度に制限されています。
|
||||
|
||||
- EscrowはXRPでのみ実行でき、発行済み通貨では実行できません。
|
||||
- Escrowでは、少なくとも2つのトランザクション（Escrowを作成するトランザクションとEscrowを終了またはキャンセルするトランザクション）を送信する必要があります。したがって、参加者は2つのトランザクションの[トランザクションコスト](transaction-cost.html)を消却する必要があるため、ごく少額の決済にEscrowを使用することは合理的ではありません。
|
||||
- Crypto-conditionを使用する場合、[EscrowFinishトランザクションのコスト](#escrowfinishトランザクションのコスト)が通常よりも高くなります。
|
||||
- Escrowはすべて、「Finish-after」時刻または[Crypto-condition][]のいずれか、またはこの両方を使用して作成する必要があります。EscrowにFinish-after時刻が設定されていない場合は、有効期限が設定されている必要があります。
|
||||
|
||||
**注記:** [fix1571 Amendment][] でEscrowの作成要件が変更されました。このAmendmentよりも前に作成されたEscrowでは、条件やFinish-after時刻を指定せずに有効期限を指定できました。このようなEscrowは誰でも即時に終了できます（資金を指定受取人に送金します）。
|
||||
|
||||
- Escrowを作成するトランザクションの実行時には、時刻の値が過去の時間であってはなりません。
|
||||
- 時限リリースおよび有効期限は、XRP Ledgerクローズに制約されます。つまり実際には、レジャーの正確なクローズ時刻に基づいて、これらの時刻が約5秒単位で丸められる場合があります。
|
||||
- サポートされている唯一の[Crypto-condition][]タイプはPREIMAGE-SHA-256です。
|
||||
|
||||
Escrowは、少量の大口決済に適した大きな保証を提供しています。[Payment Channel](use-payment-channels.html)は、迅速な小口決済に適しています。もちろん、条件無しの[決済](payment.html)も多くのユースケースで好まれます。
|
||||
|
||||
## 状態遷移図
|
||||
|
||||
次の図は、Escrow実施時の各状態を示します。
|
||||
|
||||
[](img/escrow-states.ja.png)
|
||||
|
||||
この図は、Escrowの「Finish-after」時刻（`FinishAfter`フィールド）、Crypto-condition（`Condition`フィールド）、および有効期限（`CancelAfter`フィールド）の3通りの組み合わせの3つの例を示します。
|
||||
|
||||
- **時間ベースのEscrow（左）:** Finish-after時刻のみが設定されているEscrowは、**Held**状態で作成されます。指定の時刻が経過すると**Ready**になり、誰でもこのEscrowを終了できるようになります。Escrowに有効期限が設定されており、その時刻になるまでに誰もEscrowを終了しないと、そのEscrowは**Expired**になります。Expired状態では、Escrowを終了できなくなり、誰でもEscrowをキャンセルできるようになります。Escrowに`CancelAfter`フィールドが設定されていない場合、Escrowが期限切れになることがないため、キャンセルできません。
|
||||
|
||||
- **コンビネーションEscrow（中央）:** EscrowでCrypto-condition（`Condition`フィールド） _および_ 「Finish-after」時刻（`FinishAfter` フィールド）の両方が指定されている場合、Finish-after時刻が経過するまでEscrowは**Held**状態です。その後**Conditionally Ready**になり、Crypto-conditionに対し正しいフルフィルメントを提供すればEscrowを終了できます。Escrowに有効期限（`CancelAfter`フィールド）が設定されており、その時刻になるまでに誰もEscrowを終了しないと、そのEscrowは**Expired**になります。Expired状態では、Escrowを終了できなくなり、誰でもEscrowをキャンセルできるようになります。Escrowに`CancelAfter`フィールドが設定されていない場合、Escrowが期限切れになることがないため、キャンセルできません。
|
||||
|
||||
- **条件付きEscrow（右）:** EscrowでCrypto-condition（`Condition`フィールド）が指定されており、Finish-after時刻が指定されていない場合、Escrowは作成時点で即時に**Conditionally Ready**になります。この時点では、Crypto-conditionに対する正しいフルフィルメントを提供した人だけがEscrowを終了できます。有効期限（`CancelAfter`フィールド）までに終了されなかったEscrowは**Expired**になります。（Finish-after時刻が設定されていないEscrowには、有効期限が設定されている _必要があります_ 。）Expired状態では、Escrowを終了できなくなり、誰でもEscrowをキャンセルできるようになります。
|
||||
|
||||
|
||||
|
||||
## Escrowの利用可能性
|
||||
|
||||
条件付き決済は、2017-03-31以降XRP Ledgerコンセンサスプロトコルに対する[「Escrow」Amendment](known-amendments.html#escrow)により利用可能になりました。同機能の以前のバージョンは、2016年に「Suspended Payments」（SusPay）という名称で[Ripple Test Net](https://ripple.com/build/ripple-test-net/)で利用可能になりました。
|
||||
|
||||
[スタンドアロンモード](rippled-server-modes.html#rippledサーバーをスタンドアロンモードで実行する理由)でのテストの際には、Amendmentのステータスに関係なく、Escrow機能をローカルで強制的に有効にできます。次のスタンザを`rippled.cfg`に追加してください。
|
||||
|
||||
[features]
|
||||
Escrow
|
||||
|
||||
Escrow Amendmentのステータスは、[featureメソッド][]を使用して確認できます。
|
||||
|
||||
## EscrowFinishトランザクションのコスト
|
||||
|
||||
[Crypto-condition][]を使用する場合、Crypto-conditionフルフィルメントの検証に高い処理負荷がかかるため、EscrowFinishトランザクションでは[高額なトランザクションコスト](transaction-cost.html#特別なトランザクションコスト)を支払う必要があります。
|
||||
|
||||
Escrowが時間のみによってロックされており、Crypto-conditionがない場合、EscrowFinishのコストは、リファレンストランザクションの標準[トランザクションコスト](transaction-cost.html)のみです。
|
||||
|
||||
必要となる追加のトランザクションコストは、フルフィルメントのサイズに比例します。現時点では、フルフィルメントのあるEscrowFinishでは最小トランザクションコストとして、**330 drop（[XRPのdrop数](basic-data-types.html#通貨額の指定)）と、フルフィルメントのサイズで16バイトあたり10 drop**が必要です。[マルチ署名済み](multi-signing.html)トランザクションの場合、マルチ署名のコストがフルフィルメントのコストに加算されます。
|
||||
|
||||
**注記:** 上記の式は、トランザクションのリファレンスコストがXRPの10 dropであることを前提としています。
|
||||
|
||||
[手数料投票](fee-voting.html)により`reference_fee`の値が変更される場合、この式は新しいリファレンスコストに基づいてスケーリングされます。フルフィルメントのあるEscrowFinishトランザクションの公式は次のとおりです。
|
||||
|
||||
```
|
||||
reference_fee * (signer_count + 33 + (fulfillment_bytes / 16))
|
||||
```
|
||||
|
||||
|
||||
## Escrowを使用する理由
|
||||
|
||||
従来の[Escrow](https://en.wikipedia.org/wiki/Escrow)では、特にオンラインでリスクが高いと見なされる可能性のあるさまざまな金融取引を可能にしてきました。取引期間中または評価期間中に信頼できる第三者に資金を預託することで、相手側が当事者としての責任を必ず果たすことが両者に対し保証されます。
|
||||
|
||||
Escrow機能では、第三者をXRP Ledger に組み込まれている自動システムに置き換えることで、この概念をさらに発展させました。これにより、資金のロックアップとリリースが公平に行われ、自動化できるようになりました。
|
||||
|
||||
完全に自動化されたEscrowは、XRP Ledger 自体の整合性で裏付けられており、Rippleにとって重大な問題を解決します。Escrowで実現可能なユースケースは他にも多数あると思われます。Rippleは、Escrowのユニークな活用法を新たに編み出すように業界に働きかけています。
|
||||
|
||||
### ユースケース: 時間ベースのロックアップ
|
||||
|
||||
**背景:** Rippleは大量のXRPを保有しており、XRP Ledgerと関連テクノロジーの健全な発展を促進し、資金を調達する目的でXRPを系統立てて売却しています。その一方、大量のXRPを保有しているために、Rippleでは次のような課題が生じています:
|
||||
|
||||
- XRP Ledgerを使用する個人や企業は、Rippleが市場でXRPを通常よりも高値で売却して市場へ大量供給した場合に、XRPへの投資の希薄化や価値の低下を招く可能性があると懸念しています。
|
||||
- 市場への大量売却は長期的にはRippleに損失をもたらしますが、Rippleがそのような大量売却を行う可能性は、XRP価格への押し下げ圧力を促し、Rippleの資産価値を下げることになります。
|
||||
- Rippleは、内部関係者を含め、デジタル盗難やその他の悪意のある行為からアカウントを保護するため、アカウント所有権を慎重に管理しなければなりません。
|
||||
|
||||
**解決策:** Rippleは550億XRPを時間ベースのエスクローに預託することで、XRPの供給量を予測可能なものとし、その供給量がゆっくりですが安定したペースで増加していくようにしています。XRPを保有するその他の当事者は、Rippleの優先課題や戦略が変わったとしても、同社が市場へ大量供給できないとわかっています。
|
||||
|
||||
資金をEscrowに委託しても、Rippleの保有分が不正使用者から直接保護されるわけではありませんが、不正使用者が一時的にRippleのXRPアカウントを乗っ取っても、すぐに盗んだり流用したりできるXRPの量は大幅に減少します。これによりXRPの壊滅的な損失リスクは減少し、Rippleが自社のXRP資産の不正な流用を検出、防止、追跡する時間が増加します。
|
||||
|
||||
### ユースケース: インターレジャー決済
|
||||
|
||||
**背景:** 急速に成長しているフィンテック業界の主な課題の1つに、複数のデジタル通貨システムまたはレジャー間でのアクティビティーの調整があります。この課題に対して多くの解決策（XRP Ledgerの初期ビューを含む）が提案されていますが、これは「すべてを管理する1つのレジャー」の作成に絞り込むことができます。Rippleでは、1つのシステムでは世界中のすべての人々のニーズに応えることはできないと考えています。実際に、望ましい機能のいくつかは互いに矛盾しています。Rippleではその代わりに、レジャーを相互に接続するネットワーク、つまり _インターレジャー_ に、フィンテックの未来があると考えています。[Interledger Protocol][]は、できるだけ多くのシステムを安全かつスムーズに接続するための標準を定義します。
|
||||
|
||||
インターレジャー決済の根幹をなす基本原則は、 _条件付き送金_ です。マルチホップペイメントにはリスクの問題があります。中間のホップが増えるほど、決済が失敗する箇所が増えます。インターレジャーでは、この問題が金融版「[2相コミット](https://en.wikipedia.org/wiki/Two-phase_commit_protocol)」で解決されます。この2相コミットでの2つのステップとは、（1）条件付き送金の準備と（2）送金実行のための条件のフルフィルメントです。インターレジャープロジェクトでは、条件の定義と確認を自動化する方法を標準化するために[Crypto-condition][]仕様が定義され、このような条件の「共通の土台」としてSHA-256ハッシュが定められました。
|
||||
|
||||
**解決策:** Escrow機能により、XRP LedgerはInterledger Protocolを使用したマルチホップペイメントのブリッジングに理想的なレジャーとなりました。これは、Escrow機能がPREIMAGE-SHA-256 Crypto-conditionに基づいてXRPの送金をネイティブにサポートしており、一致するフルフィルメントの提示から数秒以内にこれらの送金が実行されるためです。
|
||||
|
||||
|
||||
## 参考情報
|
||||
|
||||
XRP LedgerのEscrowの詳細は、以下を参照してください:
|
||||
|
||||
- [Escrowチュートリアル](use-escrows.html)
|
||||
- [時間に基づくEscrowの送信](send-a-time-held-escrow.html)
|
||||
- [条件に基づくEscrowの送信](send-a-conditionally-held-escrow.html)
|
||||
- [送金元または受取人別のEscrow検索](look-up-escrows.html)
|
||||
- [トランザクションのリファレンス](transaction-formats.html)
|
||||
- [EscrowCreateトランザクション][]
|
||||
- [EscrowFinishトランザクション][]
|
||||
- [EscrowCancelトランザクション][]
|
||||
- [レジャーリファレンス](ledger-data-formats.html)
|
||||
- [Escrowオブジェクト](escrow-object.html)
|
||||
|
||||
インターレジャーと、条件付き送金が実現する複数レジャー間での安全な決済についての詳細は、[Interledger Architecture](https://interledger.org/rfcs/0001-interledger-architecture/)を参照してください。
|
||||
|
||||
Rippleによる550億XRPのロックアップについては、[Ripple's Insights Blog](https://ripple.com/insights/ripple-to-place-55-billion-xrp-in-escrow-to-ensure-certainty-into-total-xrp-supply/)を参照してください。
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
111
content/concepts/payment-types/partial-payments.ja.md
Normal file
111
content/concepts/payment-types/partial-payments.ja.md
Normal file
@@ -0,0 +1,111 @@
|
||||
# Partial Payment
|
||||
|
||||
デフォルトのケースでは、XRP Ledgerの[Paymentトランザクション][]の`Amount`フィールドに、為替レートと[送金手数料](transfer-fees.html)を差し引いた実際の送金額が指定されます。「Partial Payment」フラグ（[**tfPartialPayment**](payment.html#paymentのフラグ)）を使うと、送金額を増額する代わりに受取金額を減額して、支払を正常に実行できます。Partial Paymentは、追加コストなしで[支払を返金](become-an-xrp-ledger-gateway.html#bouncing-payments)したい場合に便利です。
|
||||
|
||||
[トランザクションコスト](transaction-cost.html)に使用されるXRPの額は、トランザクションタイプに関わらず常に送金元のアカウントから差し引かれます。
|
||||
|
||||
Partial Paymentは、XRP Ledgerとのネイティブ統合を悪用して取引所およびゲートウェイから資金を盗むのに使用される恐れがあります。本書の[Partial Paymentの悪用](#partial-paymentの悪用)セクションで、この悪用の仕組みと防止対策を説明します。
|
||||
|
||||
## セマンティクス
|
||||
|
||||
### Partial Paymentを使用しない場合
|
||||
|
||||
Partial Paymentフラグを使用しないで送金する場合、トランザクションの`Amount`フィールドに実際の送金額を指定し、`SendMax`フィールドに送金上限額と通貨を指定します。`Amount`の額を全額送金すると`SendMax`パラメーターの値を超えてしまう場合や、その他何らかの理由で総額を送金できない場合は、トランザクションは失敗します。トランザクション指示で`SendMax`フィールドが省略されると、`Amount`と同額とみなされます。この場合、手数料の合計が0である場合のみ支払が成功します。
|
||||
|
||||
つまり、次の式になります。
|
||||
|
||||
Amount+（手数料）=（送金額）≤ SendMax
|
||||
|
||||
この式の「手数料」は、[送金手数料](transfer-fees.html)と通貨の為替レートを指します。送金額（`Amount`）の通貨は、送金側と受取側で異なる通貨建てにすることができ、XRP Ledgerの分散型取引所でオファーを消費することにより交換されます。
|
||||
|
||||
**注記:** トランザクションの`Fee`フィールドが参照するXRP[トランザクションコスト](transaction-cost.html)は、トランザクションをネットワークに中継するために消却されます。トランザクションコストは、常に指定通りの額が送金元から引き落とされ、あらゆるタイプの支払の手数料計算とは完全に切り離されています。
|
||||
|
||||
### Partial Paymentを使用する場合
|
||||
|
||||
Partial Paymentフラグが有効になっている支払を送金する場合、このトランザクションの`Amount`フィールドには送金限度額を指定します。Partial Paymentでは、制限（手数料、流動性不足、受取アカウントのトラストラインの枠不足など）の有無にかかわらず、指定額の _一部_ を送金できます。
|
||||
|
||||
オプションの`DeliverMin`フィールドには、送金下限額を指定します。`SendMax`フィールドは、Partial Payment以外で送金する場合と同様に機能します。Partial Paymentトランザクションは、送金額が`DeliverMin`フィールドの金額以上、`SendMax`の金額未満であれば成功します。`DeliverMin`フィールドに指定のない場合、任意の正の金額の送金であれば、Partial Paymentは成功します。
|
||||
|
||||
つまり、次の式になります。
|
||||
|
||||
金額 ≥（送金額）= SendMax -（手数料）≥ DeliverMin > 0
|
||||
|
||||
### Partial Paymentの制限事項
|
||||
|
||||
Partial Paymentには次の制限事項があります。
|
||||
|
||||
- Partial Paymentでは、アドレスにXRPにて資金を供給できません。この場合、[結果コード][]`telNO_DST_PARTIAL`が返されます。
|
||||
- Partial Paymentでは、XRP間の直接決済はできません。この場合、[結果コード][]`temBAD_SEND_XRP_PARTIAL`が返されます。
|
||||
- ただし、イシュアンスからXRPへの支払またはXRPからイシュアンスへの支払は、Partial Paymentが可能です。
|
||||
|
||||
[結果コード]: transaction-results.html
|
||||
|
||||
### `delivered_amount`フィールド
|
||||
|
||||
Partial Paymentでの実際の送金額を把握できるように、正常に完了したPaymentトランザクションのメタデータには`delivered_amount`フィールドが含まれています。このフィールドには送金額が`Amount`フィールドと[同じフォーマット](basic-data-types.html#通貨額の指定)で示されています。
|
||||
|
||||
Partial Payment以外の場合、トランザクションのメタデータの`delivered_amount`フィールドは、トランザクションの`Amount`フィールドと同じです。支払が発行済み通貨で行われた場合、丸め方により`delivered_amount`が`Amount`フィールドとやや異なることがあります。
|
||||
|
||||
次の**両方**の条件に該当するトランザクションでは、送金額を**使用できません**。
|
||||
|
||||
- Partial Paymentである
|
||||
- 2014-01-20以前の検証済みレジャーに含まれている
|
||||
|
||||
この両方の条件に該当する場合、`delivered_amount`には実際の金額ではなく文字列値`unavailable`が示されます。この状況で実際の送金額を確認する唯一の方法は、トランザクションのメタデータでAffectedNodesを参照することです。発行済み通貨を送金するトランザクションで、`Amount`の`issuer`が`Destination`アドレスと同じアカウントである場合、送金額は異なる取引相手へのトラストラインを表す複数の`AffectedNodes`メンバー間で分割できます。
|
||||
|
||||
`delivered_amount`フィールドは以下のフィールドに含まれています。
|
||||
|
||||
| API | メソッド | フィールド |
|
||||
|-----|--------|-------|
|
||||
| [JSON-RPC / WebSocket][] | [account_txメソッド][] | `result.transactions` 配列メンバーの `meta.delivered_amount` |
|
||||
| [JSON-RPC / WebSocket][] | [txメソッド][] | `result.meta.delivered_amount` |
|
||||
| [JSON-RPC / WebSocket][] | [transaction_entryメソッド][] | `result.metadata.delivered_amount` |
|
||||
| [JSON-RPC / WebSocket][] | [ledgerメソッド][]（トランザクションが展開されている状態） | `result.ledger.transactions` 配列メンバーの`metaData.delivered_amount` [新規: rippled 1.2.1][] |
|
||||
| [WebSocket][] | [トランザクションサブスクリプション](subscribe.html#トランザクションストリーム) | サブスクリプションメッセージの`meta.delivered_amount` [新規: rippled 1.2.1][] |
|
||||
| [RippleAPI][] | [`getTransaction` メソッド](rippleapi-reference.html#gettransaction) | `outcome.deliveredAmount` |
|
||||
| [RippleAPI][] | [`getTransactions` メソッド](rippleapi-reference.html#gettransaction) | 配列メンバーの `outcome.deliveredAmount` |
|
||||
|
||||
[WebSocket]: rippled-api.html
|
||||
[JSON-RPC / WebSocket]: rippled-api.html
|
||||
[RippleAPI]: rippleapi-reference.html
|
||||
|
||||
## Partial Paymentの悪用
|
||||
|
||||
金融機関によるXRP Ledgerとの統合が、Paymentの`Amount`フィールドは常に総送金額であると想定して行われる場合、不正使用者がその想定を悪用して、金融機関から資金を盗むことが可能になります。Partial Paymentがゲートウェイ、取引所、または業者のソフトウェアで正しく処理されない限り、これらの機関に対してこのような悪用が行われる可能性があります。
|
||||
|
||||
**着信Paymentトランザクションを正しく処理するには、**`Amount`フィールドではなく **[`delivered_amount`メタデータフィールド](#delivered_amountフィールド)を使用します。** これにより、金融機関が _実際の_ 受取金額を間違えることがなくなります。
|
||||
|
||||
|
||||
### 悪用シナリオの流れ
|
||||
|
||||
脆弱な金融機関を攻撃するため、不正使用者は次のような操作を試みます。
|
||||
|
||||
1. 不正使用者がPaymentトランザクションを金融機関に送信します。このトランザクションの`Amount`フィールドの額は高額で、**tfPartialPayment**フラグが有効になっています。
|
||||
2. Partial Paymentは成功しますが（結果コード`tesSUCCESS`）、実際には指定通貨でわずかな金額だけが送金されます。
|
||||
3. 脆弱な金融機関はトランザクションの`Amount`フィールドを確認しますが、`Flags`フィールドや`delivered_amount`メタデータフィールドは確認しません。
|
||||
4. 脆弱な金融機関は、XRP Ledgerへ入金された`delivered_amount`が非常に少額のであるにもかかわらず、外部システム（金融機関独自のレジャーなど）で`Amount`の総額を不正使用者に入金します。
|
||||
5. 不正使用者は、脆弱な機関がこの差異に気付く前に、可能な限りの多くの残高を別のシステムに出金します。
|
||||
- ブロックチェーントランザクションは通常不可逆であるため、不正使用者は一般的にBitcoinなどの他の仮想通貨に残高を換金することを好みます。法定通貨システムに出金した場合、金融機関がトランザクションを撤回または取り消せるのは、最初にトランザクションが実行されてから数日後になります。
|
||||
- 取引所の場合、不正使用者はXRPから残高を出金し、直接XRP Ledgerに戻すこともできます。
|
||||
|
||||
業者の場合、操作の順序がやや異なりますが、概念は同じです:
|
||||
|
||||
1. 不正使用者が大量の商品やサービスの購入を依頼します。
|
||||
2. 脆弱な業者が不正使用者に対し、購入された商品やサービスの手数料を請求します。
|
||||
3. 不正使用者がPaymentトランザクションを業者に送信します。このトランザクションの`Amount`フィールドの額は高額で、**tfPartialPayment**フラグが有効になっています。
|
||||
4. Partial Paymentが成功しますが（結果コード`tesSUCCESS`）、指定通貨でわずかな金額だけが送金されます。
|
||||
5. 脆弱な業者はトランザクションの`Amount`フィールドを確認しますが、`Flags`フィールドや`delivered_amount`メタデータフィールドは確認しません。
|
||||
6. 脆弱な業者は、XRP Ledgerへの入金された`delivered_amount` が非常に少額であるにもかかわらず、請求を支払済みとして扱い、商品またはサービスを不正使用者に納入します。
|
||||
7. 不正使用者は、業者が差異に気付く前に、商品やサービスを使用、再販売または持ち逃げします。
|
||||
|
||||
### その他の緩和対策
|
||||
|
||||
このような悪用を防ぐには、着信トランザクションの処理で[`delivered_amount`フィールド](#delivered_amountフィールド)を使用すれば十分です。ただし、積極的な取り組みを追加することによっても、このような悪用が発生する可能性を回避または緩和できます。例:
|
||||
|
||||
- 出金処理のビジネスロジックにサニティチェックを追加します。XRP Ledgerで保有している残高の合計が、予期されている資産と債務に一致しない場合は、出金を処理をしません。
|
||||
- 「顧客確認」のガイドラインに従い、顧客の身元情報を厳密に検証します。不正使用者を事前に認識して阻止したり、システムを悪用した不正使用者に対して法的措置を講じたりすることができます。
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -38,7 +38,7 @@ Partial Payments have the following limitations:
|
||||
- Direct XRP-to-XRP payments cannot be partial payments; this case returns the [result code][] `temBAD_SEND_XRP_PARTIAL`.
|
||||
- However, issuance-to-XRP payments or XRP-to-issuance payments _can_ be partial payments.
|
||||
|
||||
[result code]: reference-transaction-format.html#transaction-results
|
||||
[result code]: transaction-results.html
|
||||
|
||||
### The `delivered_amount` Field
|
||||
|
||||
@@ -73,7 +73,7 @@ You can find the `delivered_amount` field in the following places:
|
||||
|
||||
If a financial institution's integration with the XRP Ledger assumes that the `Amount` field of a Payment is always the full amount delivered, malicious actors may be able to exploit that assumption to steal money from the institution. This exploit can be used against gateways, exchanges, or merchants as long as those institutions' software does not process partial payments correctly.
|
||||
|
||||
**The correct way to process incoming Payment transactions is to use [the `delivered_amount` metadata field](#the-delivered-amount-field),** not the `Amount` field. This way, an institution is never mistaken about how much it _actually_ received.
|
||||
**The correct way to process incoming Payment transactions is to use [the `delivered_amount` metadata field](#the-delivered_amount-field),** not the `Amount` field. This way, an institution is never mistaken about how much it _actually_ received.
|
||||
|
||||
|
||||
### Exploit Scenario Steps
|
||||
@@ -100,7 +100,7 @@ In the case of a merchant, the order of operations is slightly different, but th
|
||||
|
||||
### Further Mitigations
|
||||
|
||||
Using [the `delivered_amount` field](#the-delivered-amount-field) when processing incoming transactions is enough to avoid this exploit. Still, additional proactive business practices can also avoid or mitigate the likelihood of this and similar exploits. For example:
|
||||
Using [the `delivered_amount` field](#the-delivered_amount-field) when processing incoming transactions is enough to avoid this exploit. Still, additional proactive business practices can also avoid or mitigate the likelihood of this and similar exploits. For example:
|
||||
|
||||
- Add additional sanity checks to your business logic for processing withdrawals. Never process a withdrawal if the total balance you hold in the XRP Ledger does not match your expected assets and obligations.
|
||||
- Follow "Know Your Customer" guidelines and strictly verify your customers' identities. You may be able to recognize and block malicious users in advance, or pursue legal action against a malicious actor who exploits your system.
|
||||
|
||||
37
content/concepts/payment-types/payment-channels.ja.md
Normal file
37
content/concepts/payment-types/payment-channels.ja.md
Normal file
@@ -0,0 +1,37 @@
|
||||
# Payment Channel
|
||||
|
||||
Payment Channelは、少額の単位に分割可能な「非同期」のXRPペイメントを送信し、後日決済する高度な機能です。
|
||||
|
||||
Payment Channel向けのXRPは、指定された期間にわたって留保されます。送金元がチャネルに対する _クレーム_ を作成します。受取人は、XRP Ledgerトランザクションを送信したり、新しいレジャーバージョンが[コンセンサス](consensus.html)に基づいて承認されるまで待つことなしに、このクレームを検証します。（これは、合意に基づいてトランザクションが承認される通常のパターンとは別に発生する、 _非同期_ のプロセスです。）受取人はいつでもクレームを _清算_ して、このクレームにより承認された額のXRPを受領することができます。このようなクレームを清算するときには、通常の合意プロセスの一部として標準XRP Ledgerトランザクションを使用します。この1回のトランザクションに、少額のクレームにより保証される任意の数のトランザクションを含めることができます。
|
||||
|
||||
クレームは個別に検証され、後で一括で清算できるため、Payment Channelでは、クレームのデジタル署名を作成および検証する参加者の能力によってのみ制限されるペースで、トランザクションを行えます。この制限は主に、参加者のハードウェアのスピードと、署名アルゴリズムの複雑さによるものです。最大限の速度を引き出すにはEd25519署名を使用します。これはXRP Ledgerのデフォルトのsecp256k1 ECSDA 署名よりも高速です。研究の結果、2011年のコモディティーハードウェアで[1秒あたりEd25519署名を100,000個以上作成し、1秒あたり70,000個以上を検証できることが実証されました](https://ed25519.cr.yp.to/ed25519-20110926.pdf)。
|
||||
|
||||
|
||||
## Payment Channelを使用する理由
|
||||
|
||||
Payment Channelを使用するプロセスには常に、支払人と受取人という2名の当事者が関わります。支払人とは、受取人の顧客で、XRP Ledgerを使用している個人または機関です。受取人とは、商品またはサービスの代金としてXRPを受領する個人または事業者です。
|
||||
|
||||
Payment Channelでは本来、そこで売買可能なものにいては、一切指定されません。ただし、次の商品やサービスはPayment Channelに適しています。
|
||||
|
||||
- デジタルアイテムなど、ほぼ即時に送信できるもの
|
||||
- 安価な商品（価格に占めるトランザクション処理コストの割合が大きい）
|
||||
- 通常大量購入する商品（正確な希望数量が事前に判明していない）
|
||||
|
||||
|
||||
## Payment Channelのライフサイクル
|
||||
|
||||
次の図は、Payment Channelのライフサイクルの概要を示します。
|
||||
|
||||
[](img/paychan-flow.ja.png)
|
||||
|
||||
|
||||
## 関連項目
|
||||
|
||||
- [Payment Channelの使用](use-payment-channels.html): Payment Channelを使用するプロセスを段階的に説明するチュートリアル。
|
||||
|
||||
- [Escrow](escrow.html): 速度が遅い、条件付きの大量XRP決済のための類似機能。
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
16
content/concepts/the-rippled-server/clustering.ja.md
Normal file
16
content/concepts/the-rippled-server/clustering.ja.md
Normal file
@@ -0,0 +1,16 @@
|
||||
# クラスター化
|
||||
|
||||
1つのデータセンターで複数の`rippled`サーバーを運用している場合は、これらのサーバーをクラスターに編成して、効率性を最大化できます。`rippled`サーバーをクラスターで運用するメリットは以下のとおりです。
|
||||
|
||||
- クラスター化`rippled`サーバーは暗号処理を共有します。1台のサーバーがメッセージの真正性をすでに検証している場合、クラスターの他のサーバーはそのメッセージを信頼し、再検証を行いません。
|
||||
- クラスター化サーバーは、ネットワークで不適切な活動をしているかまたはネットワークを不正使用しているピアとAPIクライアントに関する情報を共有します。このため、クラスター内のすべてのサーバーを同時に攻撃することが難しくなります。
|
||||
- クラスター化サーバーは、一部のサーバーでの現行の負荷ベースのトランザクション手数料にトランザクションが対応していない場合を含め、常にクラスター全体にトランザクションを伝搬します。
|
||||
|
||||
バリデータを[プライベートピア](peer-protocol.html#プライベートピア)として実行している場合は、`rippled`サーバーのクラスターをプロキシサーバーとして使用することが推奨されます。
|
||||
|
||||
クラスターでのサーバーの設定方法に関するチュートリアルについては、[`rippled`サーバーのクラスター化](cluster-rippled-servers.html)を参照してください。
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -0,0 +1,36 @@
|
||||
# 履歴シャーディング
|
||||
|
||||
[導入: rippled 0.90.0][]
|
||||
|
||||
稼働中のサーバーは、ネットワーク実行時に検知または取得したレジャーに関するデータを格納したデータベースを作成します。各`rippled`サーバーは、そのレジャーのデータをレジャーストアーに保存しますが、保存されたレジャー数が設定された容量制限を超えると、オンライン削除ロジックによりこれらのデータベースがローテーションされます。
|
||||
|
||||
履歴シャーディングは、XRP Ledgerのトランザクション履歴をシャードと呼ばれるセグメントに分割し、XRP Ledgerネットワークのサーバー全体に分散します。シャードは、一連のレジャーです。`rippled`サーバーは、レジャーストアーとシャードストアーの両方にレジャーを同じ方法で保存します。
|
||||
|
||||
履歴シャーディング機能を使用すると、個々の`rippled`サーバーが履歴データの保存する役割を担い、すべての履歴（数テラバイト）を保存する必要がなくなります。シャードストアーはレジャーストアーに代わるものではありませんが、XRP Ledgerネットワーク上の分散レジャー履歴への信頼性の高いパスを実現します。
|
||||
|
||||
[](img/xrp-ledger-network-ledger-store-and-shard-store.ja.png)
|
||||
|
||||
<!-- Diagram source: https://docs.google.com/presentation/d/1mg2jZQwgfLCIhOU8Mr5aOiYpIgbIgk3ymBoDb2hh7_s/edit#slide=id.g417450e8da_0_316 -->
|
||||
|
||||
## 履歴シャードの取得と共有
|
||||
|
||||
`rippled` サーバーは履歴シャードを取得して保存します（この動作には設定が必要です）。このようなサーバーでは、ネットワークとの同期を実行し、設定された数の最新レジャーへのレジャー履歴の埋め戻しが完了した後で、シャードの取得が開始されます。ネットワークアクティビティがあまり発生しないこの期間に、`shard_db`を維持するように設定されている`rippled`サーバー が、シャードストアーに追加するシャードをランダムに選択します。ネットワークレジャー履歴が均等に分散される確率を高めるため、取得対象のシャードはランダムに選択され、現行シャードが特に優先されることはありません。
|
||||
|
||||
シャードが選択されたら、レジャー取得プロセスが開始されます。最初にシャードの最後のレジャーのシーケンスが取得され、最初のシャードに向けて逆方向に処理が進められます。取得プロセスでは最初に、サーバーがローカルでデータを確認します。取得できないデータについては、サーバーはピア`rippled`サーバーにデータを要求します。要求された期間のデータを供給できるサーバーは、履歴で応答します。要求側サーバーはこれらの応答を結合し、シャードを作成します。シャードに特定範囲のレジャーがすべて含まれた状態になれば、シャードが完成します。
|
||||
|
||||
`rippled`サーバーが1つのシャードを完全に取得する前に容量不足になった場合、空き容量ができて処理を続行できるようになるまで取得プロセスを停止します。この後、古いシャードは完成された最新のシャードに置き換えられます。ディスク容量が十分にある場合は、`rippled`サーバーはシャードに割り当てられている最大ディスク容量（`max_size_gb`）に達するまで、ランダムに選択された追加のシャードを取得し、シャードストアーに追加します。
|
||||
|
||||
## XRP Ledgerネットワークデータの整合性
|
||||
|
||||
すべてのレジャーの履歴は、特定範囲の履歴レジャーを維持することに同意したサーバー間で共有されます。これにより、各サーバーは維持することに同意したデータがすべてあることを確認し、プルーフツリーまたはレジャーデルタを作成できるようになります。履歴シャーディングが設定されている`rippled`サーバーは、保存するシャードをランダムに選択するため、すべての閉鎖済みレジャーの履歴全体が正規分布曲線で保存され、XRP Ledgerネットワークで履歴が均一に維持される確率が高くなります。
|
||||
|
||||
## 関連項目
|
||||
|
||||
- [履歴シャーディングの設定](configure-history-sharding.html)
|
||||
- [download_shardメソッド][]
|
||||
- [crawl_shardsメソッド][]
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -1,6 +1,6 @@
|
||||
# History Sharding
|
||||
|
||||
[Introduced in: rippled 0.90.0][New in: rippled 0.90.0]
|
||||
[Introduced in: rippled 0.90.0][]
|
||||
|
||||
As servers operate, they naturally produce a database containing data about the ledgers they witnessed or acquired during network runtime. Each `rippled` server stores that ledger data in its ledger store, but the online delete logic rotates these databases when the number of stored ledgers exceeds configured space limitations.
|
||||
|
||||
|
||||
@@ -0,0 +1,56 @@
|
||||
# レジャー履歴
|
||||
|
||||
[コンセンサスプロセス](intro-to-consensus.html)により、[検証済みレジャーバージョン](ledgers.html)のチェーンが作成されます。各バージョンは、以前のバージョンにトランザクションのセットを適用して生成されます。各`rippled`サーバーには、レジャーバージョンとトランザクション履歴がローカルに保管されます。サーバーに保管されるトランザクション履歴の量は、サーバーがオンラインであった期間と、サーバーが取得し、保持する履歴量の設定に応じて異なります。
|
||||
|
||||
ピアツーピアのXRP Ledgerネットワーク内のサーバーは、コンセンサスプロセスの一環としてトランザクションやその他のデータを相互に共有します。各サーバーは個別に新しいレジャーバージョンを作成し、その結果を信頼できるバリデータと比較して、整合性を維持します。（信頼できるバリデータのコンセンサスがサーバーの結果と一致しない場合は、サーバーがピアから必要なデータを取得して整合性を維持します。）サーバーはピアから古いデータをダウンロードして、利用可能な履歴のギャップを埋めることができます。レジャーはデータの暗号[ハッシュ](basic-data-types.html#ハッシュ)を使用した構造となっているため、すべてのサーバーがデータの整合性の検証を行えます。
|
||||
|
||||
## データベース
|
||||
|
||||
サーバーはレジャーの状態データとトランザクションを _レジャーストアー_ と呼ばれるkey-valueストアで保持します。また、`rippled`にはいくつかのSQLiteデータベースファイルが維持されているので、トランザクション履歴などへより柔軟にアクセスし、特定の設定変更を追跡できます。
|
||||
|
||||
一般に、`rippled`サーバーが稼働していないときにはそのサーバーのすべてのデータベースファイルを安全に削除できます。（たとえばサーバーのストレージ設定を変更する場合や、Test Netから本番環境ネットワークに切り替える場合に、このような削除が必要となることがあります。）
|
||||
|
||||
## 利用可能な履歴
|
||||
|
||||
設計上、XRP Ledgerのすべてのデータとトランザクションは公開されており、誰でもすべてのデータを検索または照会できます。ただし、サーバーが検索できるデータは、そのサーバーがローカルで使用できるデータに限られます。サーバーで利用できないレジャーバージョンやトランザクションを照会しようとすると、そのデータが見つからないという応答がサーバーから返されます。必要な履歴を保持している他のサーバーに対して同じ照会を実行すると、正常な応答が返されます。XRP Ledgerデータを使用する企業では、サーバーで利用可能な履歴の量に注意してください。
|
||||
|
||||
[server_infoメソッド][]は、サーバーで利用可能なレジャーバージョンの数を`complete_ledgers`フィールドで報告します。
|
||||
|
||||
## 履歴の取得
|
||||
|
||||
`rippled`サーバーは起動されると、最優先で最新の検証済みレジャーの完全なコピーを取得します。その後、サーバーは常にレジャーの進行状況を把握します。レジャー履歴を埋め戻すように設定されているサーバーでは、レジャー履歴が設定量に達するまで埋め戻されます。この設定量は、オンライン削除による削除が開始されるカットオフ値以下でなければなりません。
|
||||
|
||||
サーバーは同期される前から履歴の埋め戻しを行い、同期後にも収集した履歴のギャップを埋めることができます。（レジャー履歴のギャップは、サーバーの使用率が一時的に高くなりネットワークと同期をとることができない場合、ネットワークとの接続が失われた場合、またはその他の一時的な問題の影響を受けた場合に発生する可能性があります。）履歴を埋め戻すため、サーバーはピア`rippled`サーバーにデータを要求します。サーバーが埋め戻す量は、`[ledger_history]`設定で定義されます。
|
||||
|
||||
XRP Ledgerは、コンテンツの一意のハッシュを使用して（さまざまなレベルの）データを識別します。XRP Ledgerの状態データには、レジャーの履歴の概要が[LedgerHashesオブジェクトタイプ](ledgerhashes.html)の形式で含まれています。サーバーはLedgerHashesオブジェクトを使用して取得するレジャーバージョンを認識し、受信するレジャーデータが正しく完全であることを確認します。
|
||||
|
||||
履歴の埋め戻しは、サーバーでは最も優先度の低い処理の1つであるため、サーバーの使用率が高い場合やハードウェアとネットワークのスペックが十分ではない場合には、欠落している履歴を埋めるのに時間がかかることがあります。推奨されるハードウェアスペックについては、[容量の計画](capacity-planning.html)を参照してください。履歴の埋め戻しでは、サーバーのダイレクトピアの1つ以上に当該の履歴が保持されている必要もあります。 <!--{# TODO: link some info for managing your peer connections when that exists #}-->
|
||||
|
||||
### 指示による削除の使用
|
||||
|
||||
[オンライン削除](online-deletion.html)と指示による削除の両方が有効な場合、サーバーでは、まだ削除が許可されていない最も古いレジャーまでのデータが自動的に埋め戻されます。これにより、`[ledger_history]`設定と`online_delete`設定で構成されているレジャーバージョンの数よりも多いデータが取得されることがあります。[can_deleteメソッド][]を実行すると、削除可能なレジャーバージョンがサーバーに通知されます。
|
||||
|
||||
|
||||
## すべての履歴
|
||||
|
||||
XRP Ledgerネットワーク内の一部のサーバーは、「すべての履歴が記録される」サーバーとして設定されています。これらのサーバーは、使用可能なすべてのXRP Ledgerの履歴を収集しますが、**オンライン削除は使用しません**。このため他の追跡サーバーよりもかなり多くのディスク容量が必要です。
|
||||
|
||||
Rippleは、`s2.ripple.com`ですべての履歴が記録される一連の公開サーバーを公開サービスとして提供しています。このサービスは、より大きなXRPコミュニティーのために提供されています。Rippleは、サーバーを悪用するユーザーや、公平な量を超えるサーバーのリソースを使用するユーザーをブロックする権利を留保しています。
|
||||
|
||||
**ヒント:** 一部の暗号資産ネットワークとは異なり、XRP Ledgerのサーバーは、現在の状態を認識して最新のトランザクションを把握するのにすべての履歴を必要としません。
|
||||
|
||||
すべての履歴の設定については、[完全な履歴の設定](configure-full-history.html)を参照してください。
|
||||
|
||||
## 履歴シャーディング
|
||||
|
||||
XRP Ledgerのすべての履歴を1台の高価なマシンに保管する代わりに、複数のサーバーがレジャー履歴の一部分を保管するように構成できます。これは[履歴シャーディング](history-sharding.html)機能によって実現します。一定範囲のレジャー履歴が _シャードストアー_ という個別の保管領域に保管されます。ピアサーバーから（上記の[履歴の取得](#履歴の取得)で説明したとおり）特定のデータが要求されると、サーバーはレジャーストアーまたはシャードストアーのデータを使用して応答できます。
|
||||
|
||||
オンライン削除ではシャードストアーのデータは削除**されません**。ただし、32768個以上のレジャーバージョンをサーバーのレジャーストアーに保持するようにオンライン削除が設定されていれば、レジャーストアーからデータが自動的に削除される前に、サーバーはレジャーストアーからシャードストアーにすべてのシャードをコピーできます。
|
||||
|
||||
詳細は、[履歴シャーディングの設定](configure-history-sharding.html)を参照してください。
|
||||
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -0,0 +1,122 @@
|
||||
# オンライン削除
|
||||
[[ソース]<br/>](https://github.com/ripple/rippled/blob/master/src/ripple/app/misc/SHAMapStoreImp.cpp "Source")
|
||||
|
||||
オンライン削除機能により、`rippled`サーバーはレジャーの古いバージョンのローカルコピーを削除できます。これにより、時間とともにディスク使用量が急増しないようにできます。デフォルトの構成ファイルにはオンライン削除の自動実行が設定されていますが、指示があった場合にのみオンライン削除を実行するようにも設定できます。[新規: rippled 0.27.0][]
|
||||
|
||||
サーバーは、レジャーおよびそのすべての残高と設定を、常に完全かつ _最新_ の状態に維持します。削除されるデータには、保存されている履歴よりも古いレジャー状態の古いトランザクションやバージョンがあります。
|
||||
|
||||
デフォルトの構成ファイルは、`rippled`サーバーが2000の最新レジャーバージョンを保持し、古いデータを自動的に削除するように設定されています。
|
||||
|
||||
**ヒント:** オンライン削除を使用しても、同一期間のレジャーデータを保管するのに必要なディスク容量は時間の経過とともに増加します。これは、個々のレジャーバージョンのサイズが時間とともに増加する傾向にあるためです。蓄積データが増加するペースは、古いレジャーを削除しない場合に比べると、非常にゆっくりとしています。必要なディスク容量に関する詳細は、[容量の計画](capacity-planning.html)を参照してください。
|
||||
|
||||
|
||||
## 背景
|
||||
|
||||
`rippled`サーバーでは[レジャー履歴](ledger-history.html)がその _レジャーストアー_ に保管されます。このデータは時間とともに蓄積されます。
|
||||
|
||||
レジャーストアー内ではレジャーデータの「重複排除」が行われます。つまり、バージョン間で変更されていないデータは1回だけ保存されます。レジャーストアーのレコード自体には、レコードが記録されているレジャーバージョンの記載はありません。オンライン削除処理において、古いレジャーバージョンでのみ使用されるレコードが特定されます。この処理には時間がかかり、またディスクI/Oとアプリケーションキャッシュに影響するため、レジャーを閉鎖するたびに古いデータを削除することは現実的ではありません。
|
||||
|
||||
|
||||
## オンライン削除の動作
|
||||
|
||||
オンライン削除の設定では、`rippled`サーバーがレジャーストアーで使用可能な状態で維持するレジャーバージョンの数が設定されます。ただし、指定される数は目安であり、厳格に適用されるものではありません。
|
||||
|
||||
- サーバーでは、設定された数のレジャーバージョンよりも新しいデータが削除されることはありませんが、長期にわたってサーバーが稼働していない場合や、ネットワークとの同期が失われた場合には、サーバーに含まれるレジャーバージョンの数が使用可能な数よりも少ないことがあります。（サーバーは一部の履歴の埋め戻しを試みます。詳細は、[履歴の取得](ledger-history.html#履歴の取得)を参照してください。）
|
||||
- オンライン削除の自動実行が設定されている場合、設定されているレジャーバージョンの数の2倍を超える数まで保存できる可能性があります。（オンライン削除を実行するたびに、保管されるレジャーバージョンの数が削減され、設定数に近くなります。）
|
||||
|
||||
ＰＣサーバーがビジーのためオンライン削除が遅延すると、レジャーバージョンが蓄積し続けることがあります。正常に動作している場合には、サーバー内のレジャーバージョン数が設定された数の2倍に達した時点でオンライン削除が開始されますが、さらにいくつかのレジャーバージョンが蓄積するまではオンライン削除が完了しないことがあります。
|
||||
|
||||
- 指示による削除が有効な場合、管理者が[can_deleteメソッド][]を呼び出すまで、サーバーが取得および作成したすべてのレジャーバージョンがサーバーに保存されます。
|
||||
|
||||
サーバーに保存されるデータ量は、[can_delete][can_deleteメソッド]を呼び出す頻度と、`online_delete`設定に指定されている期間の長さに応じて異なります。
|
||||
|
||||
- `online_delete`の間隔よりも頻繁に`can_delete`を呼び出す場合、サーバーには最大で **`online_delete`の値の2倍** にほぼ相当するレジャーバージョンが保存されます。（削除後には、この数はほぼ`online_delete`の値まで減少します。）
|
||||
|
||||
たとえば`now`値を指定した`can_delete`を1日1回呼び出し、`online_delete`に値50,000を指定している場合、削除実行前のサーバーには通常、最大100,000のレジャーバージョンが蓄積されます。削除実行後は、少なくとも50,000のレジャーバージョン（約 2日分）がサーバーに保持されます。この設定では、約1回おきに`can_delete`を呼び出しした場合、変更が生じません。これは、削除するのに十分な数のレジャーバージョンがサーバーにないためです。
|
||||
|
||||
- `online_delete`の間隔 _よりも少ない頻度で_ `can_delete`を呼び出す場合、最大で **`can_delete`呼び出しの間隔のほぼ2倍** の期間にわたりレジャーバージョンがサーバーに保管されます。（削除後には、この数は約1間隔分のデータまで減少します。）
|
||||
|
||||
たとえば`now`値を指定した`can_delete`を1日1回呼び出し、`online_delete`値に2000を指定している場合、サーバーでは通常、削除が実行されるまでに最大で2日間分のレジャーバージョンが保管されます。削除の実行後は、サーバーには約1日分のレジャーバージョン（約25,000）が保持されますが、このレジャーバージョンの数が2000を下回ることはありません。
|
||||
|
||||
|
||||
オンライン削除が有効であり、自動的に実行される場合（つまり指示による削除が無効な場合）、保管されるレジャーデータの量は、最低でもサーバーに設定された保持レジャーバージョン数に相当し、最大でその約2倍です。
|
||||
|
||||
オンライン削除が実行されても、ディスク上のSQLiteデータベースファイルのサイズは減少しません。これらのファイルの中に新しいデータを入れるのに再利用できるスペースが確保されるだけです。オンライン削除によって、レジャーストアーが含まれるRocksDB または NuDB データベースファイルのサイズは _減少します_ 。
|
||||
|
||||
サーバーでは、削除範囲を決定する際に検証済みレジャーバージョンの数だけがカウントされます。（ローカルネットワーク接続が停止していたか、グローバルXRP Ledgerネットワークがコンセンサスに達しなかったことが原因で）サーバーが新しいレジャーバージョンを検証できない例外的な状況にある場合、ネットワークが復旧した際に迅速に回復できるように、`rippled`は引き続きレジャーを閉鎖します。この場合、サーバーには未検証の閉鎖済みレジャーが多数蓄積されます。このような未検証レジャーは、オンライン削除の実行までにサーバーに保持される _検証済み_ レジャーの数には影響しません。
|
||||
|
||||
### オンライン削除の中断
|
||||
|
||||
[サーバーの状態](rippled-server-states.html)が`full`より優先順位の低い状態になると、オンライン削除は自動的に停止します。この場合、サーバーはプレフィクス`SHAMapStore::WRN`が付いたログメッセージを書き込みます。サーバーは完全に同期された後、次の検証済みレジャーバージョン以降からオンライン削除の再開を試みます。
|
||||
|
||||
サーバーを停止した場合や、オンライン削除の実行中にサーバーがクラッシュした場合には、サーバーが再起動し、完全に同期されれば、オンライン削除が再開されます。
|
||||
|
||||
オンライン削除を一時的に無効にするには、引数`never`を指定した[can_deleteメソッド][]を使用できます。この変更は、[can_delete][can_delete method] をもう一度呼び出してオンライン削除を再度有効にするまで保持されます。オンライン削除の実行時点の制御についての詳細は、[指示による削除](#指示による削除)を参照してください。
|
||||
|
||||
|
||||
## 設定
|
||||
|
||||
オンライン削除に関連する設定は以下のとおりです。
|
||||
|
||||
- **`online_delete`** - 維持する検証済みレジャーバージョンの数を指定します。サーバーは、この数よりも古いレジャーバージョンをすべて定期的に削除します。数を指定しなければ、レジャーは削除されません。
|
||||
|
||||
デフォルトの構成ファイルでは、この値は2000に設定されています。この値に256未満の数は設定はできません。これは、[手数料投票](fee-voting.html)や[Amendmentプロセス](amendments.html#amendmentプロセス)などのイベントで一度に更新されるレジャーの数が256であるためです。
|
||||
|
||||
**注意:**`online_delete`を無効にして`rippled`を実行し、その後`online_delete`を有効にしてサーバーを再起動すると、`online_delete`が無効の間にサーバーがダウンロードした既存のレジャー履歴は無視されますが、削除されません。ディスク容量を節約するには、`online_delete`設定の変更後にサーバーを再起動する前に、既存の履歴を削除します。
|
||||
|
||||
- **`[ledger_history]`** - 検証済みレジャーの数（`online_delete`の値以下）を指定します。サーバーの検証済みレジャーバージョンの数がこの数よりも少ない場合、ピアからデータを取得してバージョンを埋め戻す操作が試行されます。
|
||||
|
||||
この設定のデフォルト値はレジャー256個です。
|
||||
|
||||
次の図は、`online_delete`設定と`ledger_history`設定の関係を示します。
|
||||
|
||||
|
||||
|
||||
- **`advisory_delete`** - 有効な場合、オンライン削除は自動的にスケジュールされません。代わりに管理者が手動でオンライン削除をトリガーする必要があります。無効にするには値`0`を使用し、有効にするには`1`を使用します。
|
||||
|
||||
この設定はデフォルトで無効になっています。
|
||||
|
||||
- **`[fetch_depth]`** - 検証済みレジャーバージョンの数を指定します。サーバーは、指定されている数のレジャーバージョンよりも古い履歴データに対するピアからの取得要求を受け入れません。使用可能なすべてのデータをピアに提供するには、値`full`を指定します。
|
||||
|
||||
`fetch_depth`のデフォルトは`full`です（使用可能なすべてのデータを提供します）。
|
||||
|
||||
`fetch_depth`設定と`online_delete`設定の両方が指定されている場合、`fetch_depth`には`online_delete`よりも大きな値を設定できません。`fetch_depth`に大きな値が設定されている場合、サーバーは`fetch_depth`の値が`online_delete`と同等であるものとして扱います。
|
||||
|
||||
次の図は、fetch_depthの仕組みを示します。
|
||||
|
||||
|
||||
|
||||
さまざまな量の履歴の保管に必要なディスク容量の見積もりについては、[容量の計画](capacity-planning.html#ディスク容量)を参照してください。
|
||||
|
||||
### 指示による削除
|
||||
|
||||
デフォルトの構成ファイルでは、オンライン削除が定期的に自動で実行されるように設定されています。構成ファイルに`online_delete`間隔が指定されていない場合、オンライン削除は実行されません。構成ファイルで`advisory_delete`設定が有効になっている場合、オンライン削除は、管理者が[can_deleteメソッド][]を使用してオンライン削除をトリガーしたときにのみ実行されます。
|
||||
|
||||
指示による削除とスケジュール済みジョブを使用すれば、閉鎖済みレジャーバージョン数の代わりに、時刻に基づいて自動削除をトリガーできます。サーバーの使用率が高い場合、オンライン削除によって負荷が追加されるとサーバーの処理が遅延し、コンセンサスネットワークと一時的に非同期になることがあります。この場合は、指示による削除を使用して、オンライン削除をオフピーク期間にのみ実行するようにスケジュールできます。
|
||||
|
||||
指示による削除はその他の目的でも使用できます。たとえば、トランザクションデータを削除する前に、そのデータが別のサーバーにバックアップされていることを手動で確認できます。あるいは、トランザクションデータを削除する前に、別のタスクによるそのデータの処理が完了していることを手動で確認できます。
|
||||
|
||||
`can_delete` API メソッドは、構成ファイルで `advisory_delete` が有効になっている場合は、一般的な自動削除または特定のレジャーバージョンまでの自動削除を有効または無効にできます。`rippled`サーバーの再起動前に構成ファイルで`advisory_delete`を無効にしている場合を除き、これらの設定はサーバーを再起動しても維持されます。
|
||||
|
||||
|
||||
## 仕組み
|
||||
|
||||
オンライン削除では2つのデータベースが作成されます。このため、「古い」読み取り専用データベースと、書き込み可能な「現行」データベースが常に存在します。`rippled`サーバーはいずれかのデータベースからオブジェクトを読み取ることができます。このため、現行レジャーバージョンにはいずれかのデータベースのオブジェクトが含まれます。レジャーバージョン間でレジャー内のオブジェクトに変更がない場合、そのオブジェクトのコピーが1つだけデータベースに残ります。これにより、オブジェクトのコピーが重複してサーバーに保存されることはありません。レジャーバージョンの更新によりオブジェクトが変更されると、サーバーは変更されたオブジェクトを「新しい」データベースに保存し、古いバージョンのオブジェクト（古いレジャーバージョンで使用されているオブジェクト）は「古い」データベースに残ります。
|
||||
|
||||
オンライン削除を実行する場合、サーバーはまず、最も古いレジャーバージョンの中から保持するものを確認し、そのレジャーバージョンのすべてのオブジェクトを読み取り専用の「古い」データベースから「現行」データベースにコピーします。これにより、「現行」データベースには、選択したレジャーバージョンとそれ以降のすべての新しいバージョンで使用されるオブジェクトがすべて含まれることになります。次に、サーバーは「古い」データベースを削除し、既存の「現行」データベースを「古い」読み取り専用データベースにします。これ以降、サーバーは新しい「現行」データベースを始動し、新たな変更をすべてこのデータベースに保存します。
|
||||
|
||||
|
||||
|
||||
## 関連項目
|
||||
|
||||
- [容量の計画](capacity-planning.html)
|
||||
- [can_deleteメソッド][] - APIリファレンス資料
|
||||
- [オンライン削除の設定](configure-online-deletion.html)
|
||||
- [指示による削除の設定](configure-advisory-deletion.html)
|
||||
- [完全な履歴の設定](configure-full-history.html)
|
||||
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
75
content/concepts/the-rippled-server/peer-protocol.ja.md
Normal file
75
content/concepts/the-rippled-server/peer-protocol.ja.md
Normal file
@@ -0,0 +1,75 @@
|
||||
# ピアプロトコル
|
||||
|
||||
XRP Ledgerのサーバーは、XRP Ledgerピアプロトコル（RTXP）を使用して相互に通信します。
|
||||
|
||||
ピアプロトコルは、XRP Ledgerのサーバー間のメイン通信モードです。XRP Ledgerの動作、進捗状況、接続に関するすべての情報がピアプロトコルを通じて伝達されます。ピアツーピア通信の例を以下に示します。
|
||||
|
||||
- ピアツーピアネットワーク内の他のサーバーへの接続の要求、または接続スロットの使用可能性についてのアドバタイズ。
|
||||
- ネットワークのその他の部分との候補トランザクションの共有。
|
||||
- 履歴レジャーへのレジャーデータの要求、またはレジャーデータの提供。
|
||||
- コンセンサスのための一連のトランザクションの提示、またはコンセンサストランザクションセットの適用に関する算出結果の共有。
|
||||
|
||||
ピアツーピア接続を確立するには、サーバーどうしをHTTPSで接続し、一方のサーバーはRTXPへの切り替えのために[HTTPアップグレード](https://tools.ietf.org/html/rfc7230#section-6.7)を要求します。（詳細は、[`rippled`リポジトリ](https://github.com/ripple/rippled)の[Overlay Network](https://github.com/ripple/rippled/blob/906ef761bab95f80b0a7e0cab3b4c594b226cf57/src/ripple/overlay/README.md#handshake)を参照してください。）
|
||||
|
||||
## ピアプロトコルポート
|
||||
|
||||
XRP Ledgerに参加するため、`rippled`サーバーはピアプロトコルを使用して任意のピアに接続します。（すべてのピアは、現行サーバーで[クラスター化されている](clustering.html)場合を除き、信頼できないものとして扱われます。）
|
||||
|
||||
サーバーがピアポートで接続を送信 _かつ_ 受信できることが理想的です。ピアプロトコルに使用するポートを、ファイアウォール経由で`rippled`サーバーに転送する必要があります。[デフォルトの`rippled`構成ファイル](https://github.com/ripple/rippled/blob/master/cfg/rippled-example.cfg)は、すべてのネットワークインターフェイスでポート51235で着信ピアプロトコル接続を待機します。使用するポートを変更するには、`rippled.cfg`ファイル内の該当するスタンザを編集します。
|
||||
|
||||
例:
|
||||
|
||||
```
|
||||
[port_peer]
|
||||
port = 51235
|
||||
ip = 0.0.0.0
|
||||
protocol = peer
|
||||
```
|
||||
|
||||
ピアプロトコルポートは[特殊なPeer Crawler APIメソッド](peer-crawler.html)も処理します。
|
||||
|
||||
### ノードキーペア
|
||||
|
||||
サーバーを初めて起動すると、ピアプロトコル通信でサーバー自体を識別するための _ノードキーペア_ が生成されます。サーバーはこのキーを使用して、ピアプロトコル通信のすべてに署名します。これにより、ピアツーピアネットワーク内の別のサーバーからのメッセージの整合性を、信頼できる方法で識別、検証できます。これは、そのサーバーのメッセージが信頼できないピアにより中継される場合も同様です。
|
||||
|
||||
ノードキーペアはデータベースに保存され、サーバーの再起動時に再利用されます。サーバーのデータベースを削除すると、新しいノードキーペアが作成され、異なるアイデンティティでオンラインになります。データベースが削除されても同じキーペアを再利用するには、`[node_seed]`スタンザを使用してサーバーを設定できます。`[node_seed]`スタンザでの使用に適した値を生成するには、[validation_createメソッド][]を使用します。
|
||||
|
||||
ノードキーペアは、このサーバーと共に[クラスター化](clustering.html)されている他のサーバーも識別します。サーバークラスターを使用している場合、一意の`[node_seed]`設定を使用してクラスター内の各サーバーを構成する必要があります。クラスターの設定についての詳細は、[`rippled`サーバーのクラスター化](cluster-rippled-servers.html)を参照してください。
|
||||
|
||||
|
||||
## プライベートピア
|
||||
|
||||
`rippled`サーバーが「プライベート」サーバーとして動作するように設定し、そのIPアドレスを非公開にすることができます。これは、信頼できるバリデータなどの重要な`rippled`サーバーへのサービス拒否攻撃や侵入の試みに対する予防対策として有用です。ピアツーピアネットワークに参加するには、プライベートサーバーは1つ以上の非プライベートサーバーに接続するように設定されている必要があります。この非プライベートサーバーにより、メッセージがネットワークのその他の部分へ中継されます。
|
||||
|
||||
サーバーをプライベートサーバーとして設定すると次のさまざまな影響が生じます。
|
||||
|
||||
- サーバーがピアツーピアネットワーク内の他のサーバーに接続するように明示的に設定されていない場合、サーバーは他のサーバーに発信接続しません。
|
||||
- サーバーは、他のサーバーからの接続を受け入れるように明示的に設定されていない場合、他のサーバーからの着信接続を受け入れません。
|
||||
- サーバーはそのダイレクトピアに対し、信頼できない通信（[ピアクローラーAPI応答](peer-crawler.html)を含む）の中ではサーバーのIPアドレスを公開しないように指示します。これは、[peers adminメソッド][peers method]などの信頼できる通信には影響しません。
|
||||
|
||||
プライベートサーバーの設定に関係なく、バリデータは常にそのピアに対し、バリデータのIPアドレスを非公開にするように指示します。これにより、バリデータがサービス拒否攻撃を受け過剰な負荷がかかることから保護されます。[新規: rippled 1.2.1][]
|
||||
|
||||
**注意:** サーバーのソースコードを改ざんして、サーバーがこの要求を無視し、直近のピアのIPアドレスを共有する可能性があります。プライベートサーバーを、このように改ざんされていないことが確認されているサーバーにのみ接続するように設定してください。
|
||||
|
||||
|
||||
### プライベートサーバーの設定
|
||||
|
||||
サーバーがプライベートピアとして動作するように設定するには、`rippled`構成ファイルの`[peer_private]`スタンザを使用します。`[ips_fixed]`を使用して、サーバーの接続先サーバーをリストします。（`[ips_fixed]`にアドレスを指定せずに`[peer_private]`を有効にすると、サーバーはネットワークに接続しません。）追加の予防対策として、ファイアウォールを使用して他のサーバーからの着信接続をブロックします。
|
||||
|
||||
設定例:
|
||||
|
||||
```
|
||||
# Configuration on a private server that only connects through
|
||||
# a second rippled server at IP address 10.1.10.55
|
||||
[ips_fixed]
|
||||
10.1.10.55
|
||||
|
||||
[peer_private]
|
||||
1
|
||||
```
|
||||
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -0,0 +1,56 @@
|
||||
# rippledサーバーのモード
|
||||
|
||||
`rippled`サーバーソフトウェアは、その設定に応じて以下のようなさまざまなモードで実行できます。
|
||||
|
||||
* ストックサーバー - レジャーのローカルコピーを保持し、ネットワークをフォローします。
|
||||
* 検証サーバー（_バリデータ_）- コンセンサスの参加者（ストックサーバーの処理もすべて行います）。
|
||||
* `rippled` スタンドアロンモードのサーバー - テスト用。他の`rippled`サーバーと通信しません。
|
||||
|
||||
また、[`rippled` API](rippled-api.html)にローカルでアクセスするためのクライアントアプリケーションとして、`rippled`実行可能ファイルを実行できます。（この場合同じバイナリの2つのインスタンスを並列して実行できます。1つのインスタンスをサーバーとして実行し、もう1つのインスタンスをクライアントとして一時的に実行して終了します。）
|
||||
|
||||
各モードでrippledを実行するためのコマンドについては、[rippledコマンドライン使用リファレンス](commandline-usage.html)を参照してください。
|
||||
|
||||
|
||||
## ストックサーバーを運用する理由
|
||||
|
||||
独自の`rippled`サーバーを運用する理由は多数ありますが、その最たる理由として、独自サーバーが信頼できるものであり、自身でその負荷を管理でき、サーバーにアクセスするタイミングとアクセス方法を他のユーザーに依存せずに決めることができる点があげられます。もちろん、独自サーバーを不正使用者から保護するために適切なネットワークセキュリティ対策を講じなければなりません。
|
||||
|
||||
使用する`rippled`を信頼する必要があります。悪意のあるサーバーに接続してしまうと、そのサーバーはさまざまな方法であなたを利用して資金を失わせることができます。次に例を示します。
|
||||
|
||||
* 悪意のあるサーバーは、実際には行われていないあなたへの支払いが行われたと報告することがあります。
|
||||
* ペイメントパスと通貨取引オファーを選択的に表示または非表示にし、最適なディールをあなたに提示せずに不正使用者の利益になるようにします。
|
||||
* 悪意のあるサーバーにアドレスのシークレットキーを送信すると、このサーバーがあなたの代理として任意のトランザクションを実行し、アドレスが保有する資金全額を送金または消却することがあります。
|
||||
|
||||
さらに、独自サーバーを運用することでサーバーを制御できるようになり、重要な管理者専用コマンドや負荷の高いコマンドを実行できます。共有サーバーを使用する場合は、同じサーバーを利用する他のユーザーとサーバーのコンピューティング能力をめぐって競合することに注意する必要があります。WebSocket APIのコマンドの多くは、サーバーに大きな負荷をかけるため、`rippled`には必要に応じてその応答を縮小できるオプションがあります。サーバーを他のユーザーと共有する場合には、常に最適の結果を得られるとは限りません。
|
||||
|
||||
最後に、各自で検証サーバーを運用する場合には、ストックサーバーをパブリックネットワークへのプロキシとして使用し、ストックサーバー経由でのみ外部にアクセス可能なプライベートサブネット上で検証サーバーを維持することができます。これにより、検証サーバーの整合性を危うくすることはさらに難しくなります。
|
||||
|
||||
|
||||
## バリデータを運用する理由
|
||||
|
||||
XRP Ledgerの堅牢性は、バリデータが相互に接続されたネットワークに依存しています。各バリデータは、他の何人かのバリデータが _共謀しない_ と信頼しています。利害の異なるバリデータ運用オペレーターが増えるほど、ネットワークの各メンバーは、ネットワークが引き続き公平に運営されることに確信が持てるようになります。XRP Ledgerを使用している組織や個人の場合、コンセンサスプロセスへ参加することが自らの利益につながります。
|
||||
|
||||
すべての`rippled`サーバーをバリデータとする必要はありません。信頼する同一オペレーターのサーバーの数が増えても、共謀の発生をよりよく防止できるわけではありません。組織が自然災害などの緊急事態に備えて冗長性を保つために、複数の地域でバリデータを運用することがあります。
|
||||
|
||||
組織が検証サーバーを運用している場合は、1つ以上のストックサーバーを実行して、APIアクセスの計算負荷のバランスを取ったり、それらを検証サーバーと外部ネットワーク間のプロキシとすることもできます。
|
||||
|
||||
バリデータの実行についての詳細は、[バリデータとしての`rippled`の実行](run-rippled-as-a-validator.html)を参照してください。
|
||||
|
||||
|
||||
|
||||
## `rippled`サーバーをスタンドアロンモードで実行する理由
|
||||
|
||||
信頼できるサーバーのコンセンサスなしでも、`rippled`をスタンドアロンモードで実行できます。スタンドアロンモードでは、`rippled`はXRP Ledgerピアツーピアネットワーク内のその他のサーバーとは通信しませんが、同じ操作のほとんどをローカルサーバーのみで実行できます。スタンドアロンでは、本番環境ネットワークに接続せずに`rippled`の動作をテストできます。たとえば、分散型ネットワークにAmendmentが反映される前に、[Amendmentの効果をテスト](amendments.html#amendmentのテスト)できます。
|
||||
|
||||
`rippled`をスタンドアロンモードで実行する場合、どのレジャーバージョンから開始するかを指示する必要があります。
|
||||
|
||||
* [新しいジェネシスレジャー](start-a-new-genesis-ledger-in-stand-alone-mode.html)を最初から作成する。
|
||||
* ディスクから[既存のレジャーバージョンを読み込む](load-a-saved-ledger-in-stand-alone-mode.html)。
|
||||
|
||||
**注意:** スタンドアロンモードでは[レジャーを手動で進める](advance-the-ledger-in-stand-alone-mode.html)必要があります。
|
||||
|
||||
## 関連項目
|
||||
|
||||
- [コマンドライン使用リファレンス](commandline-usage.html) - すべての`rippled`サーバーモードのコマンドラインオプションに関する詳細情報。
|
||||
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
28
content/dev-tools/dev-tools.ja.md
Normal file
28
content/dev-tools/dev-tools.ja.md
Normal file
@@ -0,0 +1,28 @@
|
||||
# 開発者用ツール
|
||||
<!--{# TODO: Ensure that the list below follows the order of the left nav. #}-->
|
||||
|
||||
Rippleには、XRP LedgerのAPIリクエストと動作をテスト、探索、検証するための一連の開発者用ツールがそろっています。
|
||||
|
||||
* **[XRP Ledger Lookup Tool](xrp-ledger-rpc-tool.html)**
|
||||
|
||||
このJSON-RPCベースのデバッグツールを使用して、XRP Ledgerのアカウント、取引、台帳についての生データを表示します。
|
||||
|
||||
* **[XRP Ledger Test Net Faucet](xrp-test-net-faucet.html)**
|
||||
|
||||
WebSocketおよびJSON-RPC Test Netエンドポイントを使用して、XRP Ledger上で構築したソフトウェアを実際の資金を使用せずにテストします。テストの目的でTest Netのクレデンシャルと資金を生成します。Test Netの台帳と残高は定期的にリセットされます。
|
||||
<!--{# TODO: For information about how to connect your `rippled` test server to the Test Net, see [XXXXX](x). #}-->
|
||||
|
||||
* **[rippled API WebSocket Tool](websocket-api-tool.html)**
|
||||
|
||||
動作中のrippled APIを今すぐ見る必要がありますか? このツールを使用して、あらかじめ用意されたサンプル要求を送信し、応答を取得します。設定は何も必要ありません。
|
||||
<!--{# TODO: which methods are surfaced here -- is this all of them? #}-->
|
||||
|
||||
* **[Data API v2 Tool](data-api-v2-tool.html)**
|
||||
|
||||
動作中のData API v2を今すぐ見る必要がありますか? このツールを使用して、あらかじめ用意されたサンプル要求を送信し、応答を取得します。設定は何も必要ありません。
|
||||
|
||||
* **[rippled.txt Validator](ripple-txt-validator.html)**
|
||||
|
||||
このツールを使用して、「ripple.txt」が構文的に正しいことと、正しくデプロイされたことを確認します。
|
||||
|
||||
ここにないツールについて何かアイデアをお持ちですか? [お問い合わせ>](mailto:docs@ripple.com)
|
||||
5407
content/references/data-api.ja.md
Normal file
5407
content/references/data-api.ja.md
Normal file
File diff suppressed because it is too large
Load Diff
@@ -0,0 +1,64 @@
|
||||
# 管理rippledメソッド
|
||||
|
||||
`rippled`サーバーと直接通信する際には管理APIメソッドを使用します。管理メソッドは、信頼できるサーバー運用担当者のみを対象としています。管理メソッドには、サーバーの管理、監視、デバッグのためのコマンドが含まれています。
|
||||
|
||||
管理コマンドを使用できるのは、管理者として、`rippled.cfg`ファイルに指定されているホストとポートで`rippled`サーバーに接続している場合に限られます。デフォルトでは、コマンドラインクライアントが管理接続を使用します。`rippled`への接続についての詳細は、[rippled API入門](get-started-with-the-rippled-api.html)を参照してください。
|
||||
|
||||
|
||||
## [キー生成メソッド](key-generation-methods.html)
|
||||
|
||||
キーを生成および管理するには、以下のメソッドを使用します。
|
||||
|
||||
* **[`validation_create`](validation_create.html)** - 新しいrippledバリデータのキーを生成します。
|
||||
* **[`wallet_propose`](wallet_propose.html)** - 新規アカウントのキーを生成します。
|
||||
|
||||
|
||||
## [ロギングおよびデータ管理のメソッド](logging-and-data-management-methods.html)
|
||||
|
||||
ログレベルとその他のデータ（レジャーなど）の管理には、以下のメソッドを使用します。
|
||||
|
||||
* **[`can_delete`](can_delete.html)** - 特定レジャーまでのレジャーのオンライン削除を許可します。
|
||||
* **[`download_shard`](download_shard.html)** - レジャー履歴の特定のシャードをダウンロードします。
|
||||
* **[`ledger_cleaner`](ledger_cleaner.html)** - レジャークリーナーサービスが破損データを確認するように設定します。
|
||||
* **[`ledger_request`](ledger_request.html)** - ピアサーバーに対し特定のレジャーバージョンを照会します。
|
||||
* **[`log_level`](log_level.html)** - ログの詳細レベルを取得または変更します。
|
||||
* **[`logrotate`](logrotate.html)** - ログファイルを再度開きます。
|
||||
|
||||
|
||||
## [サーバー制御メソッド](server-control-methods.html)
|
||||
|
||||
rippledサーバーの管理には、以下のメソッドを使用します。
|
||||
|
||||
* **[`connect`](connect.html)** - rippledサーバーを特定のピアに強制的に接続します。
|
||||
* **[`ledger_accept`](ledger_accept.html)** - スタンドアロンモードでレジャーを閉鎖し、次のレジャーに進みます。
|
||||
* **[`stop`](stop.html)** - rippledサーバーをシャットダウンします。
|
||||
* **[`validation_seed`](validation_seed.html)** - 検証に使用するキーを一時的に設定します。
|
||||
|
||||
|
||||
## [ステータスおよびデバッグメソッド](status-and-debugging-methods.html)
|
||||
|
||||
ネットワークとサーバーのステータスを確認するには、以下のメソッドを使用します。
|
||||
|
||||
* **[`consensus_info`](consensus_info.html)** - 発生したコンセンサスの状態に関する情報を取得します。
|
||||
* **[`feature`](feature.html)** - プロトコルAmendmentに関する情報を取得します。
|
||||
* **[`fetch_info`](fetch_info.html)** - サーバーとネットワークの同期に関する情報を取得します。
|
||||
* **[`get_counts`](get_counts.html)** - サーバー内部とメモリー使用状況に関する統計情報を取得します。
|
||||
* **[`peers`](peers.html)** - 接続しているピアサーバーに関する情報を取得します。
|
||||
* **[`print`](print.html)** - 内部サブシステムに関する情報を取得します。
|
||||
* **[`validators`](validators.html)** - 現在のバリデータに関する情報を取得します。
|
||||
* **[`validator_list_sites`](validator_list_sites.html)** - バリデータリストを公開するサイトに関する情報を取得します。
|
||||
|
||||
|
||||
## 廃止予定のメソッド
|
||||
|
||||
以下の管理コマンドは廃止予定であり、今後予告なしに削除される可能性があります。
|
||||
|
||||
* `ledger_header` - 代わりに[ledgerメソッド][]を使用してください。
|
||||
* `unl_add`、`unl_delete`、`unl_list`、`unl_load`、`unl_network`、`unl_reset`、`unl_score` - 代わりに UNL管理用構成ファイルを使用してください。
|
||||
* `wallet_seed` - 代わりに[wallet_proposeメソッド][]を使用してください。
|
||||
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -0,0 +1,110 @@
|
||||
# validation_create
|
||||
[[ソース]<br>](https://github.com/ripple/rippled/blob/315a8b6b602798a4cff4d8e1911936011e12abdb/src/ripple/rpc/handlers/ValidationCreate.cpp "Source")
|
||||
|
||||
`validation_create`コマンドキーを使用して、[`rippled`サーバーがネットワークに対して自身の身元を識別させるのに使用できる暗号鍵](peer-protocol.html#ノードキーペア)を生成します。[wallet_proposeメソッド][]と同様に、このメソッドでは適切なフォーマットで一連のキーが単に生成されるだけです。XRP Ledgerのデータやサーバー構成は変更されません。
|
||||
|
||||
_`validation_create`メソッドは、権限のないユーザーは実行できない[管理メソッド](admin-rippled-methods.html)です。_
|
||||
|
||||
サーバーを設定することにより、生成されたキーペアを検証の署名（検証キーペア）に使用するか、または通常のピアツーピア通信の署名（[ノードキーペア](peer-protocol.html#ノードキーペア)）に使用するかを指定できます。
|
||||
|
||||
**ヒント:** 堅牢なバリデータを設定するには、`validator-keys`ツール（`rippled` RPMに付属）を使用してバリデータトークン（ローテーション可能）とオフラインマスターキーを生成してください。詳細は、[rippledサーバーで検証を有効化](run-rippled-as-a-validator.html#3-rippledサーバーで検証を有効化)を参照してください。
|
||||
|
||||
|
||||
### 要求フォーマット
|
||||
要求フォーマットの例:
|
||||
|
||||
<!-- MULTICODE_BLOCK_START -->
|
||||
|
||||
*WebSocket*
|
||||
|
||||
```
|
||||
{
|
||||
"id": 0,
|
||||
"command": "validation_create",
|
||||
"secret": "BAWL MAN JADE MOON DOVE GEM SON NOW HAD ADEN GLOW TIRE"
|
||||
}
|
||||
```
|
||||
|
||||
*JSON-RPC*
|
||||
|
||||
```
|
||||
{
|
||||
"method": "validation_create",
|
||||
"params": [
|
||||
{
|
||||
"secret": "BAWL MAN JADE MOON DOVE GEM SON NOW HAD ADEN GLOW TIRE"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
*コマンドライン*
|
||||
|
||||
```
|
||||
#Syntax: validation_create [secret]
|
||||
rippled validation_create "BAWL MAN JADE MOON DOVE GEM SON NOW HAD ADEN GLOW TIRE"
|
||||
```
|
||||
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
|
||||
要求には以下のパラメーターが含まれます。
|
||||
|
||||
| `Field` | 型 | 説明 |
|
||||
|:---------|:-------|:---------------------------------------------------------|
|
||||
| `secret` | 文字列 | _（省略可）_ クレデンシャルを生成するときにこの値をシードとして使用します。同じシークレットを使用すると常に同じクレデンシャルが生成されます。シードは[RFC-1751](https://tools.ietf.org/html/rfc1751)フォーマットまたはXRP Ledgerの[base58][]フォーマットで指定できます。省略すると、ランダムシードが生成されます。 |
|
||||
|
||||
**注記:** バリデータのセキュリティは、シードのエントロピーに応じて異なります。シークレット値が強力なランダム性のソースを使用して生成されている場合を除き、実際の事業目的のためにシークレット値を使用しないでください。新しいクレデンシャルを初めて生成するときには`secret`を省略することが推奨されます。
|
||||
|
||||
### 応答フォーマット
|
||||
|
||||
処理が成功した応答の例:
|
||||
|
||||
<!-- MULTICODE_BLOCK_START -->
|
||||
|
||||
*JSON-RPC*
|
||||
|
||||
```
|
||||
{
|
||||
"result" : {
|
||||
"status" : "success",
|
||||
"validation_key" : "FAWN JAVA JADE HEAL VARY HER REEL SHAW GAIL ARCH BEN IRMA",
|
||||
"validation_public_key" : "n9Mxf6qD4J55XeLSCEpqaePW4GjoCR5U1ZeGZGJUCNe3bQa4yQbG",
|
||||
"validation_seed" : "ssZkdwURFMBXenJPbrpE14b6noJSu"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
*コマンドライン*
|
||||
|
||||
```
|
||||
Loading: "/etc/rippled.cfg"
|
||||
Connecting to 127.0.0.1:5005
|
||||
{
|
||||
"result" : {
|
||||
"status" : "success",
|
||||
"validation_key" : "FAWN JAVA JADE HEAL VARY HER REEL SHAW GAIL ARCH BEN IRMA",
|
||||
"validation_public_key" : "n9Mxf6qD4J55XeLSCEpqaePW4GjoCR5U1ZeGZGJUCNe3bQa4yQbG",
|
||||
"validation_seed" : "ssZkdwURFMBXenJPbrpE14b6noJSu"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
|
||||
この応答は[標準フォーマット][]に従っており、正常に完了した場合は結果に次のフィールドが含まれています。
|
||||
|
||||
| `Field` | 型 | 説明 |
|
||||
|:------------------------|:-------|:------------------------------------------|
|
||||
| `validation_key` | 文字列 | これらの検証クレデンシャルのシークレットキー（[RFC-1751](https://tools.ietf.org/html/rfc1751)フォーマット）。 |
|
||||
| `validation_public_key` | 文字列 | これらの検証クレデンシャルの公開鍵（XRP Ledgerの[base58][]エンコード文字列フォーマット）。 |
|
||||
| `validation_seed` | 文字列 | これらの検証クレデンシャルのシークレットキー（XRP Ledgerの[base58][]エンコード文字列フォーマット）。 |
|
||||
|
||||
### 考えられるエラー
|
||||
|
||||
* [汎用エラータイプ][]のすべて。
|
||||
* `badSeed` - 要求に無効なシード値が指定されていました。この場合は通常、シード値が異なるフォーマットの有効文字列（アカウントアドレス、検証の公開鍵など）である可能性があります。
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -0,0 +1,196 @@
|
||||
# wallet_propose
|
||||
[[ソース]<br>](https://github.com/ripple/rippled/blob/master/src/ripple/rpc/handlers/WalletPropose.cpp "Source")
|
||||
|
||||
`wallet_propose`メソッドを使用して、キーペアとXRP Ledgerアドレスを生成します。このコマンドは単にキーとアドレス値を生成し、XRP Ledger自体には何ら影響しません。レジャー上で資金供給済みのアドレスになるには、そのアドレスで、[必要準備金](reserves.html)を満たすのに十分なXRPの[Paymentトランザクションを受け取る](accounts.html#アカウントの作成)必要があります。
|
||||
|
||||
*`wallet_propose`要求は、権限のないユーザーは実行できない[adminメソッド](admin-rippled-methods.html)です。*(このコマンドは、アカウントの機密情報を求めてネットワーク上の伝送情報をスニッフィングする人々から守るためにadminコマンドとされています。adminコマンドは通常、外部ネットワーク上で伝送されることはありません。）
|
||||
|
||||
[更新: rippled 0.31.0][新規: rippled 0.31.0]
|
||||
|
||||
### 要求フォーマット
|
||||
|
||||
要求フォーマットの例:
|
||||
|
||||
<!-- MULTICODE_BLOCK_START -->
|
||||
|
||||
*WebSocket（キータイプあり）*
|
||||
|
||||
```
|
||||
{
|
||||
"command": "wallet_propose",
|
||||
"seed": "snoPBrXtMeMyMHUVTgbuqAfg1SUTb",
|
||||
"key_type": "secp256k1"
|
||||
}
|
||||
```
|
||||
|
||||
*WebSocket（キータイプなし）*
|
||||
|
||||
```
|
||||
{
|
||||
"command": "wallet_propose",
|
||||
"passphrase": "masterpassphrase"
|
||||
}
|
||||
```
|
||||
|
||||
*JSON-RPC（キータイプあり）*
|
||||
|
||||
```
|
||||
{
|
||||
"method": "wallet_propose",
|
||||
"params": [
|
||||
{
|
||||
"seed": "snoPBrXtMeMyMHUVTgbuqAfg1SUTb",
|
||||
"key_type": "secp256k1"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
*JSON-RPC（キータイプなし）*
|
||||
|
||||
```
|
||||
{
|
||||
"method": "wallet_propose",
|
||||
"params": [
|
||||
{
|
||||
"passphrase": "snoPBrXtMeMyMHUVTgbuqAfg1SUTb"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
*コマンドライン*
|
||||
|
||||
```
|
||||
#Syntax: wallet_propose [passphrase]
|
||||
rippled wallet_propose masterpassphrase
|
||||
```
|
||||
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
|
||||
要求には以下のパラメーターを含めることができます。
|
||||
|
||||
| `Field` | 型 | 説明 |
|
||||
|:-------------|:-------|:-----------------------------------------------------|
|
||||
| `key_type` | 文字列 | このキーペアに使用する楕円曲線アルゴリズム。有効な値は`ed25519`と`secp256k1`（すべて小文字）です。デフォルトは`secp256k1`です。 |
|
||||
| `passphrase` | 文字列 | _（省略可能）_ このシード値からキーペアとアドレスを生成します。この値は、[16進数][]、XRP Ledgerの[base58][]フォーマット、[RFC-1751][]、または任意の文字列でフォーマットできます。`seed`または`seed_hex`とともに使用することはできません。 |
|
||||
| `seed` | 文字列 | _（省略可能）_ このシード値からXRP Ledgerの[base58][]エンコードフォーマットでキーペアとアドレスを生成します。`passphrase`または`seed_hex`とともに使用することはできません。 |
|
||||
| `seed_hex` | 文字列 | _（省略可能）_ このシード値から[16進数][]形式でキーペアとアドレスを生成します。`passphrase`または`seed`とともに使用することはできません。 |
|
||||
|
||||
以下のフィールドのうち**1つ**を指定する必要があります。`passphrase`、`seed`、または`seed_hex`。3つすべてを省略すると、`rippled`によってランダムシードが使用されます。
|
||||
|
||||
**注記:** [Ed25519](https://ed25519.cr.yp.to/)のサポートは実験的な機能です。このコマンドのコマンドラインバージョンではEd25519キーを生成できません。
|
||||
|
||||
#### シードの指定
|
||||
|
||||
ほとんどの場合、強力な乱数ソースから生成されたシード値を使用する必要があります。あるアドレスのシード値を知っている人は、[そのアドレスで署名されたトランザクションを送信する](transaction-basics.html#取引の承認)すべての権限を持っています。一般的に、ランダムシードの生成には、このコマンドにパラメーターを指定しないで実行する方法が適しています。
|
||||
|
||||
以下の場合には、既知のシードを指定します。
|
||||
|
||||
* アドレスに関連するシードのみを知っていて、アドレスを再計算する
|
||||
* `rippled`の機能をテストする
|
||||
|
||||
シードは、以下のどのフォーマットでも指定できます。
|
||||
|
||||
* XRP Ledgerの[base58][]フォーマットのシークレットキー文字列。例: `snoPBrXtMeMyMHUVTgbuqAfg1SUTb`。
|
||||
* [RFC-1751][]フォーマット文字列（secp256k1キーペアのみ）。例: `I IRE BOND BOW TRIO LAID SEAT GOAL HEN IBIS IBIS DARE`。
|
||||
* 128ビットの[16進数][]文字列。例: `DEDCE9CE67B451D852FD4E846FCDE31C`。
|
||||
* シード値として使用する任意の文字列。例: `masterpassphrase`。
|
||||
|
||||
[RFC-1751]: https://tools.ietf.org/html/rfc1751
|
||||
[16進数]: https://en.wikipedia.org/wiki/Hexadecimal
|
||||
|
||||
### 応答フォーマット
|
||||
|
||||
処理が成功した応答の例:
|
||||
|
||||
<!-- MULTICODE_BLOCK_START -->
|
||||
|
||||
*WebSocket*
|
||||
|
||||
```
|
||||
{
|
||||
"id": 2,
|
||||
"status": "success",
|
||||
"type": "response",
|
||||
"result": {
|
||||
"account_id": "rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh",
|
||||
"key_type": "secp256k1",
|
||||
"master_key": "I IRE BOND BOW TRIO LAID SEAT GOAL HEN IBIS IBIS DARE",
|
||||
"master_seed": "snoPBrXtMeMyMHUVTgbuqAfg1SUTb",
|
||||
"master_seed_hex": "DEDCE9CE67B451D852FD4E846FCDE31C",
|
||||
"public_key": "aBQG8RQAzjs1eTKFEAQXr2gS4utcDiEC9wmi7pfUPTi27VCahwgw",
|
||||
"public_key_hex": "0330E7FC9D56BB25D6893BA3F317AE5BCF33B3291BD63DB32654A313222F7FD020"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
*JSON-RPC*
|
||||
|
||||
```
|
||||
{
|
||||
"result": {
|
||||
"account_id": "rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh",
|
||||
"key_type": "secp256k1",
|
||||
"master_key": "I IRE BOND BOW TRIO LAID SEAT GOAL HEN IBIS IBIS DARE",
|
||||
"master_seed": "snoPBrXtMeMyMHUVTgbuqAfg1SUTb",
|
||||
"master_seed_hex": "DEDCE9CE67B451D852FD4E846FCDE31C",
|
||||
"public_key": "aBQG8RQAzjs1eTKFEAQXr2gS4utcDiEC9wmi7pfUPTi27VCahwgw",
|
||||
"public_key_hex": "0330E7FC9D56BB25D6893BA3F317AE5BCF33B3291BD63DB32654A313222F7FD020",
|
||||
"status": "success"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
*コマンドライン*
|
||||
|
||||
```
|
||||
Loading: "/etc/rippled.cfg"
|
||||
Connecting to 127.0.0.1:5005
|
||||
{
|
||||
"result" : {
|
||||
"account_id" : "rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh",
|
||||
"key_type" : "secp256k1",
|
||||
"master_key" : "I IRE BOND BOW TRIO LAID SEAT GOAL HEN IBIS IBIS DARE",
|
||||
"master_seed" : "snoPBrXtMeMyMHUVTgbuqAfg1SUTb",
|
||||
"master_seed_hex" : "DEDCE9CE67B451D852FD4E846FCDE31C",
|
||||
"public_key" : "aBQG8RQAzjs1eTKFEAQXr2gS4utcDiEC9wmi7pfUPTi27VCahwgw",
|
||||
"public_key_hex" : "0330E7FC9D56BB25D6893BA3F317AE5BCF33B3291BD63DB32654A313222F7FD020",
|
||||
"status" : "success"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
|
||||
応答は[標準フォーマット][]に従い、正常に終了した場合、新しい（可能性がある）アカウントについての重要な各種情報を含みます。以下のフィールドを含みます。
|
||||
|
||||
| `Field` | 型 | 説明 |
|
||||
|:------------------|:-------|:------------------------------------------------|
|
||||
| `master_seed` | 文字列 | これはキーペアの秘密鍵です。このアカウントに関するその他のあらゆる情報が、マスターシードからXRP Ledgerの[base58][]エンコード文字列フォーマットで引き出されます。通常、このフォーマットのキーを使用してトランザクションに署名します。 |
|
||||
| `master_seed_hex` | 文字列 | 16進数形式のマスターシード。単純で広く支持されている秘密鍵表示法。トランザクションの署名に使用できます。 |
|
||||
| `master_key` | 文字列 | [RFC 1751](http://tools.ietf.org/html/rfc1751)フォーマットのマスターシード。覚えやすく書き留めやすい秘密鍵。トランザクションの署名に使用できます。 |
|
||||
| `account_id` | 文字列 | XRP Ledgerの[base58][]フォーマットで作成されたアカウントの[アドレス][]。これは公開鍵ではありませんが、公開鍵を2回ハッシュ化したものです。チェックサムも持っているため、タイプミスした場合はほぼ間違いなく無効なアドレスとみなされ、有効だが異なるアドレスとはみなされません。これはXRP LedgerのアカウントのプライマリIDです。支払いを受けるときにこれを人に伝えたり、トランザクションにおいて、自身や、支払先、委託先識別するのに使用します。[マルチ署名のリスト](multi-signing.html)でもこれを使用して、他の署名者を識別します。 |
|
||||
| `public_key` | 文字列 | XRP Ledgerの[base58][]エンコード文字列フォーマットで作成された、キーペアの公開鍵。`master_seed`から生成されます。 |
|
||||
| `public_key_hex` | 文字列 | これは16進数で作成されたキーペアの公開鍵です。`master_seed`から生成されます。トランザクションの署名を検証する場合、`rippled`にはこの公開鍵が必要です。そのため、署名されたトランザクションのフォーマットの`SigningPubKey`フィールドには公開鍵が入力されています。 |
|
||||
| `warning` | 文字列 | （削除される可能性あり）要求にシード値を指定した場合、このフィールドに安全でない可能性があるという警告が表示されます。[新規: rippled 0.32.0][] |
|
||||
|
||||
このメソッドを使用してキーペアを生成し、アカウントのレギュラーキーペアとして使用することもできます。アカウントにレギュラーキーペアを割り当てて、それを使用してほとんどのトランザクションに署名し、マスターキーペアをできるだけオフラインにしておくことも可能です。
|
||||
|
||||
レギュラーキーペアとして使用するほかに、マルチ署名のリスト（SignerList）のメンバーとして使用することもできます。
|
||||
|
||||
マスターキーペアとレギュラーキーペアの詳細は、[暗号鍵](cryptographic-keys.html)を参照してください。
|
||||
|
||||
マルチ署名の詳細は、[マルチ署名](multi-signing.html)を参照してください。
|
||||
|
||||
|
||||
### 考えられるエラー
|
||||
|
||||
* いずれかの[汎用エラータイプ][]。
|
||||
* `invalidParams` - 1つ以上のフィールドが不正に指定されています。
|
||||
* `badSeed` - 要求には、空の文字列やXRP Ledgerアドレスに似た文字列などの許可されないシード値が（`passphrase`、`seed`、または`seed_hex`フィールド内に）指定されています。
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -5,7 +5,7 @@ Use the `wallet_propose` method to generate a key pair and XRP Ledger address. T
|
||||
|
||||
*The `wallet_propose` method is an [admin method](admin-rippled-methods.html) that cannot be run by unprivileged users!* (This command is restricted to protect against people sniffing network traffic for account secrets, since admin commands are not usually transmitted over the outside network.)
|
||||
|
||||
[Updated in: rippled 0.31.0][New in: rippled 0.31.0]
|
||||
[Updated in: rippled 0.31.0][]
|
||||
|
||||
### Request Format
|
||||
|
||||
|
||||
@@ -0,0 +1,78 @@
|
||||
# can_delete
|
||||
[[ソース]<br>](https://github.com/ripple/rippled/blob/master/src/ripple/rpc/handlers/CanDelete.cpp "Source")
|
||||
|
||||
`can_delete`メソッドは`rippled`サーバーに対し最新のレジャーバージョンを通知します。この最新バージョンは[指示による削除が有効なオンライン削除](online-deletion.html#指示による削除)を使用するときに削除できます。指示による削除が有効ではない場合、このメソッドは何も行いません。<!-- NOTE: I'm pretty sure this is slightly wrong. --@mDuo13 -->
|
||||
|
||||
_`can_delete`メソッドは、権限のないユーザーは実行できない[管理メソッド](admin-rippled-methods.html)です。_
|
||||
|
||||
### 要求フォーマット
|
||||
|
||||
要求フォーマットの例:
|
||||
|
||||
<!-- MULTICODE_BLOCK_START -->
|
||||
|
||||
*WebSocket*
|
||||
|
||||
```
|
||||
{
|
||||
"id": 2,
|
||||
"command": "can_delete",
|
||||
"can_delete": 11320417
|
||||
}
|
||||
```
|
||||
|
||||
*JSON-RPC*
|
||||
|
||||
```
|
||||
{
|
||||
"method": "can_delete",
|
||||
"params": [
|
||||
{
|
||||
"can_delete": 11320417
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
*コマンドライン*
|
||||
|
||||
```
|
||||
#Syntax can_delete [<ledger_index>|<ledger_hash>|now|always|never]
|
||||
rippled can_delete 11320417
|
||||
```
|
||||
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
|
||||
要求には以下のパラメーターを指定できます。
|
||||
|
||||
| `Field` | 型 | 説明 |
|
||||
|:-------------|:------------------|:------------------------------------------|
|
||||
| `can_delete` | 文字列 または整数 | _（省略可）_ 削除可能な最大レジャーバージョンの[レジャーインデックス][]。特殊ケース`never`を指定すると、オンライン削除が無効になります。特殊ケース`always`を指定すると、指示による削除が無効な場合と同様に、自動オンライン削除が有効になります。特殊ケース`now`を指定すると、設定されている`online_delete`値に一致するかまたはこの値を超える次の検証済みレジャーで、オンライン削除が1回実行されます。省略すると、サーバーは変更を行いません（ただし現在の`can_delete`の値で応答します）。 |
|
||||
|
||||
### 応答フォーマット
|
||||
|
||||
応答は[標準フォーマット][]に従っており、正常に完了した場合は結果に次のフィールドが含まれています。
|
||||
|
||||
| `Field` | 型 | 説明 |
|
||||
|:-------------|:--------|:----------------------------------------------------|
|
||||
| `can_delete` | 整数 | オンライン削除ルーチンにより削除できる最大レジャーインデックス。 |
|
||||
|
||||
既存の`can_delete`設定を照会する場合は、パラメーターを指定せずにこのコマンドを実行します。
|
||||
|
||||
### 考えられるエラー
|
||||
|
||||
- [汎用エラータイプ][]のすべて。
|
||||
- `invalidParams` - 1つ以上のフィールドの指定が正しくないか、1つ以上の必須フィールドが指定されていません。
|
||||
- `lgrNotFound` 要求の`can_delete`フィールドに指定されているレジャーが存在しないか、存在しているがサーバーにはありません。
|
||||
- `notEnabled` - オンライン削除または指示による削除のいずれかがサーバーの設定で有効になっていない場合。
|
||||
- `notReady` - サーバーは現在オンライン削除を実行する準備ができていません。これは通常、サーバーが起動したが、検証済みレジャーをまだ取得していないことを意味します。
|
||||
|
||||
## 参照項目
|
||||
|
||||
- [オンライン削除](online-deletion.html)
|
||||
- [指示による削除の設定](configure-advisory-deletion.html)
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -0,0 +1,122 @@
|
||||
# download_shard
|
||||
[[ソース]<br>](https://github.com/ripple/rippled/blob/master/src/ripple/rpc/handlers/DownloadShard.cpp "Source")
|
||||
|
||||
サーバーに対し、外部ソースから特定の[履歴レジャーデータのシャード](history-sharding.html)をダウンロードするように指示します。`rippled`サーバーで[履歴シャードが保管されるように設定する](configure-history-sharding.html)必要があります。[新規: rippled 1.1.0][]
|
||||
|
||||
_`download_shard`メソッドは、権限のないユーザーは実行できない[管理メソッド](admin-rippled-methods.html)です。_
|
||||
|
||||
外部ソースからHTTPSを使用してシャードが[lz4圧縮](https://lz4.github.io/lz4/) [tarアーカイブ](https://en.wikipedia.org/wiki/Tar_(computing)) として提供される必要があります。このアーカイブの内容が、シャードストアーに使用されるデータベースタイプ（NuDBまたはRocksDB）と一致する必要があります。
|
||||
|
||||
通常、このメソッドを使用してシャードをダウンロードしてインポートすれば、ピアツーピアネットワークからシャードを個別に取得するよりも短い時間で取得できます。また、サーバーから提供される特定範囲のシャードまたはシャードのセットを選択する場合にもこのメソッドを使用できます。
|
||||
|
||||
### 要求フォーマット
|
||||
|
||||
要求フォーマットの例:
|
||||
|
||||
<!-- MULTICODE_BLOCK_START -->
|
||||
|
||||
*WebSocket*
|
||||
|
||||
```json
|
||||
{
|
||||
"command": "download_shard",
|
||||
"shards": [
|
||||
{"index": 1, "url": "https://example.com/1.tar.lz4"},
|
||||
{"index": 2, "url": "https://example.com/2.tar.lz4"},
|
||||
{"index": 5, "url": "https://example.com/5.tar.lz4"}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
*JSON-RPC*
|
||||
|
||||
```json
|
||||
{
|
||||
"method": "download_shard",
|
||||
"params": [
|
||||
{
|
||||
"shards": [
|
||||
{"index": 1, "url": "https://example.com/1.tar.lz4"},
|
||||
{"index": 2, "url": "https://example.com/2.tar.lz4"},
|
||||
{"index": 5, "url": "https://example.com/5.tar.lz4"}
|
||||
]
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
|
||||
|
||||
要求には以下のフィールドが含まれます。
|
||||
|
||||
| `Field` | 型 | 説明 |
|
||||
|:-----------|:--------|:------------------------------------------------------|
|
||||
| `shards` | 配列 | ダウンロードするシャードとダウンロード元を記述したShard Descriptorオブジェクト（以下の説明を参照）のリスト。 |
|
||||
| `validate` | ブール値 | _（省略可）_`false`の場合はダウンロードしたデータの検証をスキップします。デフォルトは`true`です。この場合、アーカイブのシャードにシャードのデータオブジェクトがすべて含まれており、シャードが現行の検証済みレジャーのレジャー履歴の一部であるか否かが確認されます。 |
|
||||
|
||||
`shards`配列の各**Shard Descriptorオブジェクト**には以下のフィールドが含まれています。
|
||||
|
||||
| `Field` | 型 | 説明 |
|
||||
|:--------|:-------|:----------------------------------------------------------|
|
||||
| `index` | 数値 | 取得するシャードのインデックス。本番環境のXRP Ledgerでは、最も古いシャードのインデックスは1であり、このシャードにはレジャー32750～32768が含まれています。次のシャードのインデックスは2であり、このシャードにはレジャー32769～49152が含まれています。 |
|
||||
| `url` | 文字列 | このシャードをダウンロードできるURL。このURLは`https://`で始まり`.tar.lz4`（大文字小文字の区別なし）で終わる必要があります。このダウンロードを提供するWebサーバーは、信頼できる認証局（CA）によって署名された有効なTLS証明書を使用する必要があります。（`rippled`はオペレーティングシステムのCAストアーを使用します。） |
|
||||
|
||||
### 応答フォーマット
|
||||
|
||||
処理が成功した応答の例:
|
||||
|
||||
<!-- MULTICODE_BLOCK_START -->
|
||||
|
||||
*WebSocket*
|
||||
|
||||
```json
|
||||
{
|
||||
"result": {
|
||||
"message": "downloading shards 1-2,5"
|
||||
},
|
||||
"status": "success",
|
||||
"type": "response"
|
||||
}
|
||||
```
|
||||
|
||||
|
||||
*JSON-RPC*
|
||||
|
||||
```json
|
||||
200 OK
|
||||
|
||||
{
|
||||
"result": {
|
||||
"message": "downloading shards 1-2,5",
|
||||
"status": "success"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
|
||||
この応答は[標準フォーマット][]に従っており、正常に完了した場合は結果に次のフィールドが含まれています。
|
||||
|
||||
| `Field` | 型 | 説明 |
|
||||
|:----------|:-------|:--------------------------------------------------------|
|
||||
| `message` | 文字列 | この要求に対応して実行されたアクションを説明するメッセージ。 |
|
||||
|
||||
**ヒント:** サーバーで使用可能なシャードを確認するには、シャードストアーとして設定されたロケーションのサブフォルダー（`rippled.cfg`の`[shard_db]`の`path`パラメーター）を調べます。フォルダーには、シャードの番号に対応する名前が付いています。これらのフォルダーの1つに、シャードが未完了であることを示す`control.txt`ファイルが含まれていることがあります。 <!-- TODO: Update to recommend the `crawl_shards` command if/when that command becomes available. -->
|
||||
|
||||
### 考えられるエラー
|
||||
|
||||
- [汎用エラータイプ][]のすべて。
|
||||
- `notEnabled` - サーバーでシャードストアーを使用するように設定されていません。
|
||||
- `tooBusy` - サーバーはすでに、ピアツーピアネットワークから、または以前の`download_shard`要求の結果として、シャードをダウンロード中です。
|
||||
- `invalidParams` - 要求で1つ以上の必須フィールドが省略されていたか、または指定されたフィールドのデータタイプが誤っています。
|
||||
|
||||
<!--{# @mduo13's note: Was unable to reproduce the following feature:
|
||||
**Tip:** If you make the request with the WebSocket API, the server can notify you over the same WebSocket connection if the download fails or an error occurs while extracting the archive. TODO: Get an example of what this message looks like. #}-->
|
||||
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -0,0 +1,73 @@
|
||||
# ledger_cleaner
|
||||
[[ソース]<br>](https://github.com/ripple/rippled/blob/df54b47cd0957a31837493cd69e4d9aade0b5055/src/ripple/rpc/handlers/LedgerCleaner.cpp "Source")
|
||||
|
||||
`ledger_cleaner`コマンドは[レジャークリーナー](https://github.com/ripple/rippled/blob/f313caaa73b0ac89e793195dcc2a5001786f916f/src/ripple/app/ledger/README.md#the-ledger-cleaner)を制御します。レジャークリーナーは、`rippled`のレジャーデータベースの破損を検出して修復できる非同期メンテナンスプロセスです。
|
||||
|
||||
_`ledger_cleaner`メソッドは、権限のないユーザーは実行できない[管理メソッド](admin-rippled-methods.html)です。_
|
||||
|
||||
### 要求フォーマット
|
||||
要求フォーマットの例:
|
||||
|
||||
<!-- MULTICODE_BLOCK_START -->
|
||||
|
||||
*WebSocket*
|
||||
|
||||
```
|
||||
{
|
||||
"command": "ledger_cleaner",
|
||||
"max_ledger": 13818756,
|
||||
"min_ledger": 13818000,
|
||||
"stop": false
|
||||
}
|
||||
```
|
||||
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
|
||||
要求には以下のパラメーターが含まれます。
|
||||
|
||||
| `Field` | 型 | 説明 |
|
||||
|:--------------|:--------------------------------|:---------------------------|
|
||||
| `ledger` | 数値（レジャーシーケンス番号） | _（省略可）_ 指定されている場合は、このレジャーのみをチェックして訂正します。 |
|
||||
| `max_ledger` | 数値（レジャーシーケンス番号） | _（省略可）_ シーケンス番号がこの番号以下のレジャーをチェックするようにレジャークリーナーを設定します。 |
|
||||
| `min_ledger` | 数値（レジャーシーケンス番号） | _（省略可）_ シーケンス番号がこの番号以上のレジャーをチェックするようにレジャークリーナーを設定します。 |
|
||||
| `full` | ブール値 | _（省略可）_ trueの場合は、指定されたレジャーのレジャー状態オブジェクトとトランザクションを修正します。デフォルトではfalseです。`ledger`が指定されている場合は、自動的に`true`に設定されます。 |
|
||||
| `fix_txns` | ブール値 | _（省略可）_ trueの場合は、指定されたレジャーのトランザクションを修正します。指定されている場合は`full`をオーバーライドします。 |
|
||||
| `check_nodes` | ブール値 | _（省略可）_ trueの場合は、指定されているレジャーのレジャー状態オブジェクトを修正します。指定されている場合は`full`をオーバーライドします。 |
|
||||
| `stop` | ブール値 | _（省略可）_ trueの場合は、レジャークリーナーを無効にします。 |
|
||||
|
||||
### 応答フォーマット
|
||||
|
||||
処理が成功した応答の例:
|
||||
|
||||
<!-- MULTICODE_BLOCK_START -->
|
||||
|
||||
*JSON-RPC*
|
||||
|
||||
```
|
||||
200 OK
|
||||
{
|
||||
"result" : {
|
||||
"message" : "Cleaner configured",
|
||||
"status" : "success"
|
||||
}
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
|
||||
この応答は[標準フォーマット][]に従っており、正常に完了した場合は結果に次のフィールドが含まれています。
|
||||
|
||||
| `Field` | 型 | 説明 |
|
||||
|:----------|:-------|:---------------------------------|
|
||||
| `message` | 文字列 | `Cleaner configured` : 正常終了の場合。 |
|
||||
|
||||
### 考えられるエラー
|
||||
|
||||
* [汎用エラータイプ][]のすべて。
|
||||
* `internal` : いずれかのパラメーターが正しく指定されていない場合。（これはバグです。本来のエラーコードは`invalidParams`です。）
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -0,0 +1,183 @@
|
||||
# ledger_request
|
||||
[[ソース]<br>](https://github.com/ripple/rippled/blob/e980e69eca9ea843d200773eb1f43abe3848f1a0/src/ripple/rpc/handlers/LedgerRequest.cpp "Source")
|
||||
|
||||
`ledger_request`コマンドは、サーバーに対し接続しているピアから特定のレジャーバージョンを取得するように指示します。これは、サーバーが直接接続しているピアの1つにそのレジャーが存在している場合にのみ機能します。場合によっては、レジャーを完全に取得するにはこのコマンドを繰り返し実行する必要があります。
|
||||
|
||||
*`ledger_request`要求は、権限のないユーザーは実行できない[管理メソッド](admin-rippled-methods.html)です。*
|
||||
|
||||
### 要求フォーマット
|
||||
要求フォーマットの例:
|
||||
|
||||
<!-- MULTICODE_BLOCK_START -->
|
||||
|
||||
*WebSocket*
|
||||
|
||||
```
|
||||
{
|
||||
"id": 102,
|
||||
"command": "ledger_request",
|
||||
"ledger_index": 13800000
|
||||
}
|
||||
```
|
||||
|
||||
*コマンドライン*
|
||||
|
||||
```
|
||||
rippled ledger_request 13800000
|
||||
```
|
||||
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
|
||||
要求には以下のパラメーターが含まれます。
|
||||
|
||||
| `Field` | 型 | 説明 |
|
||||
|:---------------|:-------|:---------------------------------------------------|
|
||||
| `ledger_index` | 数値 | _（省略可）_[レジャーインデックス][]により指定されたレジャーを取得します。 |
|
||||
| `ledger_hash` | 文字列 | _（省略可）_ 識別用[ハッシュ][]により指定されたレジャーを取得します。 |
|
||||
|
||||
`ledger_index`または`ledger_hash`のいずれかを指定する必要がありますが、両方は指定しないでください。
|
||||
|
||||
### 応答フォーマット
|
||||
|
||||
応答は[標準フォーマット][]に従っています。ただし、_`rippled`サーバーに対してレジャーの取得開始を正常に指示できた場合でも_、指定されたレジャーがない場合には失敗を示す応答が要求から返されます。
|
||||
|
||||
**注記:** レジャーを取得するには、rippledサーバーのダイレクトピアの履歴にそのレジャーが含まれている必要があります。どのピアにも要求されたレジャーがない場合は、[connectメソッド][]または構成ファイルの`fixed_ips`セクションを使用して、`s2.ripple.com`にあるRippleのすべての履歴が記録されるサーバーを追加すれば、`ledger_request`要求を再度実行できます。
|
||||
|
||||
失敗した場合の応答には、レジャーの取得状況が示されます。成功した場合の応答には、[ledgerメソッド][]に類似したフォーマットでレジャーの情報が含まれます。
|
||||
|
||||
<!-- MULTICODE_BLOCK_START -->
|
||||
|
||||
*コマンドライン（失敗）*
|
||||
|
||||
```
|
||||
Loading: "/etc/rippled.cfg"
|
||||
Connecting to 127.0.0.1:5005
|
||||
{
|
||||
"result" : {
|
||||
"acquiring" : {
|
||||
"hash" : "01DDD89B6605E20338B8EEB8EB2B0E0DD2F685A2B164F3790C4D634B5734CC26",
|
||||
"have_header" : false,
|
||||
"peers" : 2,
|
||||
"timeouts" : 0
|
||||
},
|
||||
"error" : "lgrNotFound",
|
||||
"error_code" : 20,
|
||||
"error_message" : "acquiring ledger containing requested index",
|
||||
"request" : {
|
||||
"command" : "ledger_request",
|
||||
"ledger_index" : 18851277
|
||||
},
|
||||
"status" : "error"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
*コマンドライン（進行中）*
|
||||
|
||||
```
|
||||
Loading: "/etc/rippled.cfg"
|
||||
Connecting to 127.0.0.1:5005
|
||||
{
|
||||
"result" : {
|
||||
"hash" : "EB68B5B4F6F06BF59B6D7532BCB98BB98E2F10C2435D895217AA0AA7E910FBD5",
|
||||
"have_header" : true,
|
||||
"have_state" : false,
|
||||
"have_transactions" : false,
|
||||
"needed_state_hashes" : [
|
||||
"C46F7B9E795135447AF24BAF999AB8FC1612A997F6EAAF8B784C226FF0BD8E25",
|
||||
"E48F528E4FC2A1DC492C6264B27B420E2285B2A3ECF3A253DB480DA5BFB7F858",
|
||||
"B62CD0B2E1277F78BC279FA037F3F747587299B60D23A551C3F63DD137DC0CF8",
|
||||
"30014C55701FB8426E496A47B297BEC9E8F5BFA47763CC22DBD9024CC81D39DD",
|
||||
"7EB59A853913898FCEA7B701637F33B1054BD36C32A0B910B612EFB9CDFF6334",
|
||||
"07ECAD3066D62583883979A2FADAADC8F7D89FA07375843C8A47452639AB2421",
|
||||
"97A87E5246AF78463485CB27E08D561E22AAF33D5E2F08FE2FACAE0D05CB5478",
|
||||
"50A0525E238629B32324C9F59B4ECBEFE3C21DC726DB9AB3B6758BD1838DFF68",
|
||||
"8C541B1ED47C9282E2A28F0B7F3DDFADF06644CAB71B15A3E67D04C5FAFE9BF4",
|
||||
"2C6CC536C778D8C0F601E35DA7DD9888C288897E4F603E76357CE2F47E8A7A9F",
|
||||
"309E78DEC67D5725476A59E114850556CC693FB6D92092997ADE97E3EFF473CC",
|
||||
"8EFF61B6A636AF6B4314CAC0C08F4FED0759E1F782178A822EDE98275E5E4B10",
|
||||
"9535645E5D249AC0B6126005B79BB981CBA00286E00154D20A3BCF65743EA3CA",
|
||||
"69F5D6FCB41D1E6CEA5ADD42CBD194086B45E957D497DF7AEE62ADAD485660CE",
|
||||
"07E93A95DBB0B8A00925DE0DF6D27E41CACC77EF75055A89815006109D82EAD3",
|
||||
"7FDF25F660235DCAD649676E3E6729DF920A9B0B4B6A3B090A3C64D7BDE2FB20"
|
||||
],
|
||||
"needed_transaction_hashes" : [
|
||||
"BA914854F2F5EDFCBD6E3E0B168E5D4CD0FC92927BEE408C6BD38D4F52505A34",
|
||||
"AE3A2DB537B01EB33BB3A677242DE52C9AE0A64BD9222EE55E52855276E7EA2A",
|
||||
"E145F737B255D93769673CBA6DEBA4F6AC7387A309DAACC72EA5B07ECF03C215",
|
||||
"073A118552AA60E1D3C6BE6F65E4AFA01C582D9C41CCC2887244C19D9BFA7741",
|
||||
"562DB8580CD3FE19AF5CEA61C2858C10091151B924DBF2AEB7CBB8722E683204",
|
||||
"437C0D1C2391057079E9539CF028823D29E6437A965284F6E54CEBF1D25C5D56",
|
||||
"1F069486AF5533883609E5C8DB907E97273D9A782DF26F5E5811F1C42ED63A3D",
|
||||
"CAA6B7DA68EBA71254C218C81A9EA029A179694BDD0D75A49FB03A7D57BCEE49"
|
||||
],
|
||||
"peers" : 6,
|
||||
"status" : "success",
|
||||
"timeouts" : 1
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
*コマンドライン（成功）*
|
||||
|
||||
```
|
||||
Loading: "/etc/rippled.cfg"
|
||||
Connecting to 127.0.0.1:5005
|
||||
{
|
||||
"result" : {
|
||||
"ledger" : {
|
||||
"accepted" : true,
|
||||
"account_hash" : "84EBB27D9510AD5B9A3A328201921B3FD418D4A349E85D3DC69E33C7B506407F",
|
||||
"close_time" : 486691300,
|
||||
"close_time_human" : "2015-Jun-04 00:01:40",
|
||||
"close_time_resolution" : 10,
|
||||
"closed" : true,
|
||||
"hash" : "DCF5D723ECEE1EF56D2B0024CD9BDFF2D8E3DC211BD2B9460165922564ACD863",
|
||||
"ledger_hash" : "DCF5D723ECEE1EF56D2B0024CD9BDFF2D8E3DC211BD2B9460165922564ACD863",
|
||||
"ledger_index" : "13840000",
|
||||
"parent_hash" : "8A3F6FBC62C11DE4538D969F9C7966234635FE6CEB1133DDC37220978F8100A9",
|
||||
"seqNum" : "13840000",
|
||||
"totalCoins" : "99999022883526403",
|
||||
"total_coins" : "99999022883526403",
|
||||
"transaction_hash" : "3D759EF3AF1AE2F78716A8CCB2460C3030F82687E54206E883703372B9E1770C"
|
||||
},
|
||||
"ledger_index" : 13840000,
|
||||
"status" : "success"
|
||||
}
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
|
||||
3つの応答フォーマットは次のとおりです。
|
||||
|
||||
1. `lgrNotFound`エラーが返された場合、応答の`acquiring`フィールドには、ピアツーピアネットワークからのレジャー取得状況を示す[レジャー要求オブジェクト](#レジャー要求オブジェクト)が指定されています。
|
||||
2. サーバーが現在データを取得中であると応答に示される場合、その結果の本文として、ピアツーピアネットワークからのレジャー取得状況を示す[レジャー要求オブジェクト](#レジャー要求オブジェクト)が表示されます。
|
||||
3. レジャーが完全に利用可能な場合、応答には[レジャーヘッダー](ledger-header.html)が表示されます。
|
||||
|
||||
### レジャー要求オブジェクト
|
||||
|
||||
サーバーでレジャーの取得操作が進行中であり、まだ完了していない場合は、`rippled`サーバーはレジャー取得状況を示すレジャー要求オブジェクトを返します。このオブジェクトのフィールドを次に示します。
|
||||
|
||||
| `Field` | 型 | 説明 |
|
||||
|:----------------------------|:-----------------|:----------------------------|
|
||||
| `hash` | 文字列 | （省略される場合があります）要求されるレジャーの[ハッシュ][]（サーバーがこのハッシュを認識している場合）。 |
|
||||
| `have_header` | ブール値 | 要求されたレジャーのヘッダーセクションがサーバーにあるかどうか。 |
|
||||
| `have_state` | ブール値 | （省略される場合があります）要求されたレジャーの[アカウント状態セクション](ledgers.html#ツリーの形式)がサーバーにあるかどうか。 |
|
||||
| `have_transactions` | ブール値 | （省略される場合があります）要求されたレジャーのトランザクションセクションがサーバーにあるかどうか。 |
|
||||
| `needed_state_hashes` | 文字列の配列 | （省略される場合があります）サーバーが取得する必要がある[状態ツリー](ledgers.html#ツリーの形式)内のオブジェクトのハッシュ（最大16個）。 |
|
||||
| `needed_transaction_hashes` | 文字列の配列 | （省略される場合があります）サーバーが取得する必要があるトランザクションツリー内のオブジェクトのハッシュ（最大16個）。 |
|
||||
| `peers` | 数値 | このレジャーを見つけるためにサーバーが照会するピアの数。 |
|
||||
| `timeouts` | 数値 | これまでにこのレジャーの取得操作がタイムアウトした回数。 |
|
||||
|
||||
### 考えられるエラー
|
||||
|
||||
* [汎用エラータイプ][]のすべて。
|
||||
* `invalidParams` - 1つ以上のフィールドの指定が正しくないか、1つ以上の必須フィールドが指定されていません。このエラーは、指定したレジャーインデックスが現在進行中のレジャーのインデックス以上である場合にも発生します。
|
||||
* `lgrNotFound` - レジャーがまだ利用可能ではない場合。これは、サーバーがレジャーの取得を開始していますが、要求されたレジャーが接続されたどのピアにもない場合には失敗する可能性があることを意味します。（以前はこのエラーにはコード`ledgerNotFound`が使用されていました。）[更新: rippled 0.30.1][新規: rippled 0.30.1]
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -175,7 +175,7 @@ When the server is in the progress of fetching a ledger, but has not yet finishe
|
||||
|
||||
* Any of the [universal error types][].
|
||||
* `invalidParams` - One or more fields are specified incorrectly, or one or more required fields are missing. This error can also occur if you specify a ledger index equal or higher than the current in-progress ledger.
|
||||
* `lgrNotFound` - If the ledger is not yet available. This indicates that the server has started fetching the ledger, although it may fail if none of its connected peers have the requested ledger. (Previously, this error used the code `ledgerNotFound` instead.) [Updated in: rippled 0.30.1][New in: rippled 0.30.1]
|
||||
* `lgrNotFound` - If the ledger is not yet available. This indicates that the server has started fetching the ledger, although it may fail if none of its connected peers have the requested ledger. (Previously, this error used the code `ledgerNotFound` instead.) [Updated in: rippled 0.30.1][]
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
|
||||
@@ -0,0 +1,140 @@
|
||||
# log_level
|
||||
[[ソース]<br>](https://github.com/ripple/rippled/blob/155fcdbcd0b4927152892c8c8be01d9cf62bed68/src/ripple/rpc/handlers/LogLevel.cpp "Source")
|
||||
|
||||
`log_level`コマンドは`rippled`サーバーのログ詳細レベルを変更するか、各ログメッセージカテゴリー（_パーティション_）の現在のログレベルを返します。
|
||||
|
||||
_`log_level`メソッドは、権限のないユーザーは実行できない[管理メソッド](admin-rippled-methods.html)です。_
|
||||
|
||||
### 要求フォーマット
|
||||
要求フォーマットの例:
|
||||
|
||||
<!-- MULTICODE_BLOCK_START -->
|
||||
|
||||
*WebSocket*
|
||||
|
||||
```
|
||||
{
|
||||
"id": "ll1",
|
||||
"command": "log_level",
|
||||
"severity": "debug",
|
||||
"partition": "PathRequest"
|
||||
}
|
||||
```
|
||||
|
||||
*コマンドライン*
|
||||
|
||||
```
|
||||
#Syntax: log_level [[partition] severity]
|
||||
rippled log_level PathRequest debug
|
||||
```
|
||||
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
|
||||
要求には以下のパラメーターが含まれます。
|
||||
|
||||
| `Field` | 型 | 説明 |
|
||||
|:------------|:-------|:------------------------------------------------------|
|
||||
| `severity` | 文字列 | _（省略可）_ 設定するログの詳細レベル。以下に、有効な値を詳細レベルの低いものから順に示します。`fatal`、`error`、`warn`、`info`、`debug`、および`trace`。省略すると、すべてのカテゴリーの現在のログ詳細レベルが返されます。 |
|
||||
| `partition` | 文字列 | _（省略可）_`severity`が指定されていない場合は無視されます。変更するログカテゴリー。省略されている場合、または`base`の値が指定されている場合は、すべてのカテゴリーのログレベルを設定します。 |
|
||||
|
||||
### 応答フォーマット
|
||||
|
||||
成功した場合の応答例:
|
||||
|
||||
<!-- MULTICODE_BLOCK_START -->
|
||||
|
||||
*コマンドライン（ログレベルの設定）*
|
||||
|
||||
```
|
||||
Loading: "/etc/rippled.cfg"
|
||||
Connecting to 127.0.0.1:5005
|
||||
{
|
||||
"result" : {
|
||||
"status" : "success"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
*コマンドライン（ログレベルの確認）*
|
||||
|
||||
```
|
||||
Loading: "/etc/rippled.cfg"
|
||||
Connecting to 127.0.0.1:5005
|
||||
{
|
||||
"result" : {
|
||||
"levels" : {
|
||||
"AmendmentTable" : "Error",
|
||||
"Application" : "Error",
|
||||
"CancelOffer" : "Error",
|
||||
"Collector" : "Error",
|
||||
"CreateOffer" : "Error",
|
||||
"DeferredCredits" : "Error",
|
||||
"FeeVote" : "Error",
|
||||
"InboundLedger" : "Error",
|
||||
"JobQueue" : "Error",
|
||||
"Ledger" : "Error",
|
||||
"LedgerCleaner" : "Error",
|
||||
"LedgerConsensus" : "Error",
|
||||
"LedgerEntrySet" : "Error",
|
||||
"LedgerMaster" : "Error",
|
||||
"LedgerTiming" : "Error",
|
||||
"LoadManager" : "Error",
|
||||
"LoadMonitor" : "Error",
|
||||
"NetworkOPs" : "Error",
|
||||
"NodeObject" : "Error",
|
||||
"OrderBookDB" : "Error",
|
||||
"Overlay" : "Error",
|
||||
"PathRequest" : "Debug",
|
||||
"Payment" : "Error",
|
||||
"Peer" : "Error",
|
||||
"PeerFinder" : "Error",
|
||||
"Protocol" : "Error",
|
||||
"RPC" : "Error",
|
||||
"RPCErr" : "Error",
|
||||
"RPCHandler" : "Error",
|
||||
"RPCManager" : "Error",
|
||||
"Resolver" : "Error",
|
||||
"Resource" : "Error",
|
||||
"RippleCalc" : "Error",
|
||||
"SHAMap" : "Error",
|
||||
"SHAMapStore" : "Error",
|
||||
"SNTPClient" : "Error",
|
||||
"STAmount" : "Error",
|
||||
"SerializedLedger" : "Error",
|
||||
"Server" : "Error",
|
||||
"SetAccount" : "Error",
|
||||
"SetTrust" : "Error",
|
||||
"TaggedCache" : "Error",
|
||||
"TransactionAcquire" : "Error",
|
||||
"TransactionEngine" : "Error",
|
||||
"UVL" : "Error",
|
||||
"UniqueNodeList" : "Error",
|
||||
"Validations" : "Error",
|
||||
"WALCheckpointer" : "Error",
|
||||
"WebSocket" : "Trace",
|
||||
"base" : "Error"
|
||||
},
|
||||
"status" : "success"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
|
||||
応答は[標準フォーマット][]に従っています。応答フォーマットは、要求に`severity`が指定されているかどうかに応じて異なります。指定されていた場合はログレベルが変更され、成功した場合の結果には追加フィールドが含まれません。
|
||||
|
||||
それ以外の場合、要求には以下のフィールドが含まれます。
|
||||
|
||||
| `Field` | 型 | 説明 |
|
||||
|:--------|:-------|:----------------------------------------------------------|
|
||||
| `level` | オブジェクト | 各カテゴリーの現在のログレベル。このカテゴリーリストは、今後のリリースで予告なく変更される場合があります。このコマンドに対する要求で、フィールド名を`partition`の値として使用できます。 |
|
||||
|
||||
### 考えられるエラー
|
||||
|
||||
* [汎用エラータイプ][]のすべて。
|
||||
* `invalidParams` - 1つ以上のフィールドの指定が正しくないか、1つ以上の必須フィールドが指定されていません。
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -0,0 +1,80 @@
|
||||
# logrotate
|
||||
[[ソース]<br>](https://github.com/ripple/rippled/blob/743bd6c9175c472814448ea889413be79dfd1c07/src/ripple/rpc/handlers/LogRotate.cpp "Source")
|
||||
|
||||
`logrotate`コマンドは、ログファイルを閉じて再度開きます。これは、Linuxファイルシステムでのログローテーションを促進することを目的としています。
|
||||
|
||||
_`logrotate`メソッドは、権限のないユーザーは実行できない[管理メソッド](admin-rippled-methods.html)です。_
|
||||
|
||||
### 要求フォーマット
|
||||
要求フォーマットの例:
|
||||
|
||||
<!-- MULTICODE_BLOCK_START -->
|
||||
|
||||
*WebSocket*
|
||||
|
||||
```
|
||||
{
|
||||
"id": "lr1",
|
||||
"command": "logrotate"
|
||||
}
|
||||
```
|
||||
|
||||
*コマンドライン*
|
||||
|
||||
```
|
||||
rippled logrotate
|
||||
```
|
||||
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
|
||||
要求にはパラメーターが含まれていません。
|
||||
|
||||
### 応答フォーマット
|
||||
|
||||
処理が成功した応答の例:
|
||||
|
||||
<!-- MULTICODE_BLOCK_START -->
|
||||
|
||||
*JSON-RPC*
|
||||
|
||||
```
|
||||
200 OK
|
||||
{
|
||||
"result" : {
|
||||
"message" : "The log file was closed and reopened.",
|
||||
"status" : "success"
|
||||
}
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
*コマンドライン*
|
||||
|
||||
```
|
||||
Loading: "/etc/rippled.cfg"
|
||||
Connecting to 127.0.0.1:5005
|
||||
{
|
||||
"result" : {
|
||||
"message" : "The log file was closed and reopened.",
|
||||
"status" : "success"
|
||||
}
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
|
||||
応答は[標準フォーマット][]に従っており、正常に完了した場合は結果に次のフィールドが含まれています。
|
||||
|
||||
| `Field` | 型 | 説明 |
|
||||
|:----------|:-------|:--------------------------------------------------------|
|
||||
| `message` | 文字列 | 正常に完了した場合、次のメッセージが含まれています。 `The log file was closed and reopened.` |
|
||||
|
||||
### 考えられるエラー
|
||||
|
||||
* [汎用エラータイプ][]のすべて。
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -0,0 +1,101 @@
|
||||
# connect
|
||||
[[ソース]<br>](https://github.com/ripple/rippled/blob/a61ffab3f9010d8accfaa98aa3cacc7d38e74121/src/ripple/rpc/handlers/Connect.cpp "Source")
|
||||
|
||||
`connect`コマンドは、`rippled`サーバーを特定のピア`rippled`サーバーに強制的に接続します。
|
||||
|
||||
*`connect`要求は、権限のないユーザーは実行できない[管理メソッド](admin-rippled-methods.html)です。*
|
||||
|
||||
### 要求フォーマット
|
||||
要求フォーマットの例:
|
||||
|
||||
<!-- MULTICODE_BLOCK_START -->
|
||||
|
||||
*WebSocket*
|
||||
|
||||
```
|
||||
{
|
||||
"command": "connect",
|
||||
"ip": "192.170.145.88",
|
||||
"port": 51235
|
||||
}
|
||||
```
|
||||
|
||||
*JSON-RPC*
|
||||
|
||||
```
|
||||
{
|
||||
"method": "connect",
|
||||
"params": [
|
||||
{
|
||||
"ip": "192.170.145.88",
|
||||
"port": 51235
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
|
||||
*コマンドライン*
|
||||
|
||||
```
|
||||
#Syntax: connect ip [port]
|
||||
rippled connect 192.170.145.88 51235
|
||||
```
|
||||
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
|
||||
要求には以下のパラメーターが含まれます。
|
||||
|
||||
| `Field` | 型 | 説明 |
|
||||
|:--------|:-------|:----------------------------------------------------------|
|
||||
| `ip` | 文字列 | 接続するサーバーのIPアドレス。 |
|
||||
| `port` | 数値 | _（省略可）_ 接続時に使用するポート番号。デフォルトでは6561です。 |
|
||||
|
||||
### 応答フォーマット
|
||||
|
||||
処理が成功した応答の例:
|
||||
|
||||
<!-- MULTICODE_BLOCK_START -->
|
||||
|
||||
*JSON-RPC*
|
||||
|
||||
```
|
||||
{
|
||||
"result" : {
|
||||
"message" : "connecting",
|
||||
"status" : "success"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
*コマンドライン*
|
||||
|
||||
```
|
||||
Loading: "/etc/rippled.cfg"
|
||||
Connecting to 127.0.0.1:5005
|
||||
{
|
||||
"result" : {
|
||||
"message" : "connecting",
|
||||
"status" : "success"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
|
||||
この応答は[標準フォーマット][]に従っており、正常に完了した場合は結果に次のフィールドが含まれています。
|
||||
|
||||
| `Field` | 型 | 説明 |
|
||||
|:----------|:-------|:-------------------------------------------------------|
|
||||
| `message` | 文字列 | コマンドが成功した場合の値は`connecting`。 |
|
||||
|
||||
### 考えられるエラー
|
||||
|
||||
* [汎用エラータイプ][]のすべて。
|
||||
* `invalidParams` - 1つ以上のフィールドの指定が正しくないか、1つ以上の必須フィールドが指定されていません。
|
||||
* スタンドアロンモードでは接続できません - スタンドアロンモードではネットワーク関連のコマンドが無効にされています。
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -0,0 +1,64 @@
|
||||
# ledger_accept
|
||||
[[ソース]<br>](https://github.com/ripple/rippled/blob/a61ffab3f9010d8accfaa98aa3cacc7d38e74121/src/ripple/rpc/handlers/LedgerAccept.cpp "Source")
|
||||
|
||||
`ledger_accept`メソッドは、サーバーが現在処理中のレジャーを強制的に終了し、次のレジャー番号に進むようにします。このメソッドはテスト専用であり、`rippled`サーバーがスタンドアロンモードで実行されている場合にのみ使用できます。
|
||||
|
||||
*`ledger_accept`メソッドは、権限のないユーザーは実行できない[管理メソッド](admin-rippled-methods.html)です。*
|
||||
|
||||
### 要求フォーマット
|
||||
|
||||
要求フォーマットの例:
|
||||
|
||||
<!-- MULTICODE_BLOCK_START -->
|
||||
|
||||
*WebSocket*
|
||||
|
||||
```
|
||||
{
|
||||
"id": "Accept my ledger!",
|
||||
"command": "ledger_accept"
|
||||
}
|
||||
```
|
||||
|
||||
*コマンドライン*
|
||||
|
||||
```
|
||||
#Syntax: ledger_accept
|
||||
rippled ledger_accept
|
||||
```
|
||||
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
|
||||
この要求はパラメーターを受け入れません。
|
||||
|
||||
### 応答フォーマット
|
||||
|
||||
処理が成功した応答の例:
|
||||
```js
|
||||
{
|
||||
"id": "Accept my ledger!",
|
||||
"status": "success",
|
||||
"type": "response",
|
||||
"result": {
|
||||
"ledger_current_index": 6643240
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
応答は[標準フォーマット][]に従っており、正常に完了した場合は結果に次のフィールドが含まれます。
|
||||
|
||||
| `Field` | 型 | 説明 |
|
||||
|:-----------------------|:-----------------|:---------------------------------|
|
||||
| `ledger_current_index` | 符号なし整数 | 新規に作成される「現行」レジャーのシーケンス番号 |
|
||||
|
||||
**注記:** レジャーを閉鎖すると、`rippled`がそのレジャーのトランザクションの正規順序を決定してリプレイします。これにより、以前に現行レジャーに暫定的に適用されていたトランザクションの結果が変化することがあります。
|
||||
|
||||
### 考えられるエラー
|
||||
|
||||
* [汎用エラータイプ][]のすべて。
|
||||
* `notStandAlone` - `rippled`サーバーが現在スタンドアロンモードで実行されていない場合。
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -0,0 +1,88 @@
|
||||
# stop
|
||||
[[ソース]<br>](https://github.com/ripple/rippled/blob/master/src/ripple/rpc/handlers/Stop.cpp "Source")
|
||||
|
||||
サーバーのグレースフルシャットダウンを行います。
|
||||
|
||||
_`stop`要求は、権限のないユーザーは実行できない*[管理メソッド](admin-rippled-methods.html)です。_
|
||||
|
||||
### 要求フォーマット
|
||||
要求フォーマットの例:
|
||||
|
||||
<!-- MULTICODE_BLOCK_START -->
|
||||
|
||||
*WebSocket*
|
||||
|
||||
```
|
||||
{
|
||||
"id": 0,
|
||||
"command": "stop"
|
||||
}
|
||||
```
|
||||
|
||||
*JSON-RPC*
|
||||
|
||||
```
|
||||
{
|
||||
"method": "stop",
|
||||
"params": [
|
||||
{}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
*コマンドライン*
|
||||
|
||||
```
|
||||
rippled stop
|
||||
```
|
||||
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
|
||||
要求にはパラメーターが含まれていません。
|
||||
|
||||
### 応答フォーマット
|
||||
|
||||
処理が成功した応答の例:
|
||||
|
||||
<!-- MULTICODE_BLOCK_START -->
|
||||
|
||||
*JSON-RPC*
|
||||
|
||||
```
|
||||
{
|
||||
"result" : {
|
||||
"message" : "ripple server stopping",
|
||||
"status" : "success"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
*コマンドライン*
|
||||
|
||||
```
|
||||
Loading: "/etc/rippled.cfg"
|
||||
Connecting to 127.0.0.1:5005
|
||||
{
|
||||
"result" : {
|
||||
"message" : "ripple server stopping",
|
||||
"status" : "success"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
|
||||
応答は[標準フォーマット][]に従っており、正常に完了した場合は結果に次のフィールドが含まれています。
|
||||
|
||||
| `Field` | 型 | 説明 |
|
||||
|:----------|:-------|:-------------------------------------|
|
||||
| `message` | 文字列 | `ripple server stopping` : 正常終了の場合。 |
|
||||
|
||||
### 考えられるエラー
|
||||
|
||||
* [汎用エラータイプ][]のすべて。
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -0,0 +1,91 @@
|
||||
# validation_seed
|
||||
[[ソース]<br>](https://github.com/ripple/rippled/blob/a61ffab3f9010d8accfaa98aa3cacc7d38e74121/src/ripple/rpc/handlers/ValidationSeed.cpp "Source")
|
||||
|
||||
`validation_seed`コマンドは、rippledが検証の署名に使用するシークレット値を一時的に設定します。サーバーを再起動すると、この値は構成ファイルに基づいてリセットされます。[rippled 0.29.1 以降では無効](https://github.com/ripple/rippled/releases/tag/0.29.1-rc1 "BADGE_RED")
|
||||
|
||||
*`validation_seed`要求は、権限のないユーザーは実行できない[管理メソッド](admin-rippled-methods.html)です。*
|
||||
|
||||
### 要求フォーマット
|
||||
要求フォーマットの例:
|
||||
|
||||
<!-- MULTICODE_BLOCK_START -->
|
||||
|
||||
*WebSocket*
|
||||
|
||||
```
|
||||
{
|
||||
"id": "set_seed_1",
|
||||
"command": "validation_seed",
|
||||
"secret": "BAWL MAN JADE MOON DOVE GEM SON NOW HAD ADEN GLOW TIRE"
|
||||
}
|
||||
```
|
||||
|
||||
*コマンドライン*
|
||||
|
||||
```
|
||||
#Syntax: validation_seed [secret]
|
||||
rippled validation_seed 'BAWL MAN JADE MOON DOVE GEM SON NOW HAD ADEN GLOW TIRE'
|
||||
```
|
||||
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
|
||||
要求には以下のパラメーターが含まれます。
|
||||
|
||||
| `Field` | 型 | 説明 |
|
||||
|:---------|:-------|:---------------------------------------------------------|
|
||||
| `secret` | 文字列 | _（省略可）_ 指定されている場合は、この値はキーペアの検証のためのシークレット値として使用されます。有効なフォーマットには、XRP Ledgerの[base58][]フォーマット、[RFC-1751](https://tools.ietf.org/html/rfc1751)、またはパスフレーズがあります。省略されている場合は、ネットワークへの検証の提案が無効になります。 |
|
||||
|
||||
### 応答フォーマット
|
||||
|
||||
処理が成功した応答の例:
|
||||
|
||||
<!-- MULTICODE_BLOCK_START -->
|
||||
|
||||
*JSON-RPC*
|
||||
|
||||
```
|
||||
200 OK
|
||||
{
|
||||
"result" : {
|
||||
"status" : "success",
|
||||
"validation_key" : "BAWL MAN JADE MOON DOVE GEM SON NOW HAD ADEN GLOW TIRE",
|
||||
"validation_public_key" : "n9Jx6RS6zSgqsgnuWJifNA9EqgjTKAywqYNReK5NRd1yLBbfC3ng",
|
||||
"validation_seed" : "snjJkyBGogTem5dFGbcRaThKq2Rt3"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
*コマンドライン*
|
||||
|
||||
```
|
||||
Loading: "/etc/rippled.cfg"
|
||||
Connecting to 127.0.0.1:5005
|
||||
{
|
||||
"result" : {
|
||||
"status" : "success",
|
||||
"validation_key" : "BAWL MAN JADE MOON DOVE GEM SON NOW HAD ADEN GLOW TIRE",
|
||||
"validation_public_key" : "n9Jx6RS6zSgqsgnuWJifNA9EqgjTKAywqYNReK5NRd1yLBbfC3ng",
|
||||
"validation_seed" : "snjJkyBGogTem5dFGbcRaThKq2Rt3"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
|
||||
この応答は[標準フォーマット][]に従っており、正常に完了した場合は結果に次のフィールドが含まれています。
|
||||
|
||||
| `Field` | 型 | 説明 |
|
||||
|:------------------------|:-------|:------------------------------------------|
|
||||
| `validation_key` | 文字列 | （提案が無効な場合には省略可）これらの検証クレデンシャルのシークレットキー（[RFC-1751](https://tools.ietf.org/html/rfc1751)フォーマット）。 |
|
||||
| `validation_public_key` | 文字列 | （提案が無効な場合には省略可）これらの検証クレデンシャルの公開鍵（XRP Ledgerの[base58][]エンコード文字列フォーマット） |
|
||||
| `validation_seed` | 文字列 | （提案が無効な場合には省略可）これらの検証クレデンシャルのシークレットキー（XRP Ledgerの[base58][]エンコード文字列フォーマット） |
|
||||
|
||||
### 考えられるエラー
|
||||
|
||||
* [汎用エラータイプ][]のすべて。
|
||||
* `badSeed` - 要求に無効なシークレット値が指定されていました。この場合は通常、シークレット値が異なるフォーマットの有効文字列（アカウントアドレス、検証の公開鍵など）である可能性があります。
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -0,0 +1,233 @@
|
||||
# consensus_info
|
||||
[[ソース]<br>](https://github.com/ripple/rippled/blob/a61ffab3f9010d8accfaa98aa3cacc7d38e74121/src/ripple/rpc/handlers/ConsensusInfo.cpp "Source")
|
||||
|
||||
`consensus_info`コマンドは、デバッグのためのコンセンサスプロセスに関する情報を返します。
|
||||
|
||||
_`consensus_info`メソッドは、権限のないユーザーは実行できない[管理メソッド](admin-rippled-methods.html)です。_
|
||||
|
||||
### 要求フォーマット
|
||||
要求フォーマットの例:
|
||||
|
||||
<!-- MULTICODE_BLOCK_START -->
|
||||
|
||||
*WebSocket*
|
||||
|
||||
```
|
||||
{
|
||||
"id": 99,
|
||||
"command": "consensus_info"
|
||||
}
|
||||
```
|
||||
|
||||
*JSON-RPC*
|
||||
|
||||
```
|
||||
{
|
||||
"method": "consensus_info",
|
||||
"params": [
|
||||
{}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
*コマンドライン*
|
||||
|
||||
```
|
||||
#Syntax: consensus_info
|
||||
rippled consensus_info
|
||||
```
|
||||
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
|
||||
この要求にはパラメーターはありません。
|
||||
|
||||
### 応答フォーマット
|
||||
|
||||
処理が成功した応答の例:
|
||||
|
||||
<!-- MULTICODE_BLOCK_START -->
|
||||
|
||||
*JSON-RPC*
|
||||
|
||||
```
|
||||
{
|
||||
"result" : {
|
||||
"info" : {
|
||||
"acquired" : {
|
||||
"4BC2CE596CBD1321775320E2067F9C06D3862826212C16EF42ABB6A2B0414306" : "acquired"
|
||||
},
|
||||
"close_granularity" : 10,
|
||||
"close_percent" : 50,
|
||||
"close_resolution" : 10,
|
||||
"close_times" : {
|
||||
"486082972" : 1,
|
||||
"486082973" : 4
|
||||
},
|
||||
"current_ms" : 1003,
|
||||
"have_time_consensus" : false,
|
||||
"ledger_seq" : 13701086,
|
||||
"our_position" : {
|
||||
"close_time" : 486082973,
|
||||
"previous_ledger" : "0BB01379B51234BAAF501A71C7AB147F595460B689BB9E8252A0B87B5A483623",
|
||||
"propose_seq" : 0,
|
||||
"transaction_hash" : "4BC2CE596CBD1321775320E2067F9C06D3862826212C16EF42ABB6A2B0414306"
|
||||
},
|
||||
"peer_positions" : {
|
||||
"0A2EAF919033A036D363D4E5610A66209DDBE8EE" : {
|
||||
"close_time" : 486082972,
|
||||
"peer_id" : "n9KiYM9CgngLvtRCQHZwgC2gjpdaZcCcbt3VboxiNFcKuwFVujzS",
|
||||
"previous_ledger" : "0BB01379B51234BAAF501A71C7AB147F595460B689BB9E8252A0B87B5A483623",
|
||||
"propose_seq" : 0,
|
||||
"transaction_hash" : "4BC2CE596CBD1321775320E2067F9C06D3862826212C16EF42ABB6A2B0414306"
|
||||
},
|
||||
"1567A8C953A86F8428C7B01641D79BBF2FD508F3" : {
|
||||
"close_time" : 486082973,
|
||||
"peer_id" : "n9LdgEtkmGB9E2h3K4Vp7iGUaKuq23Zr32ehxiU8FWY7xoxbWTSA",
|
||||
"previous_ledger" : "0BB01379B51234BAAF501A71C7AB147F595460B689BB9E8252A0B87B5A483623",
|
||||
"propose_seq" : 0,
|
||||
"transaction_hash" : "4BC2CE596CBD1321775320E2067F9C06D3862826212C16EF42ABB6A2B0414306"
|
||||
},
|
||||
"202397A81F20B44CF44EA99AF761295E5A8397D2" : {
|
||||
"close_time" : 486082973,
|
||||
"peer_id" : "n9MD5h24qrQqiyBC8aeqqCWvpiBiYQ3jxSr91uiDvmrkyHRdYLUj",
|
||||
"previous_ledger" : "0BB01379B51234BAAF501A71C7AB147F595460B689BB9E8252A0B87B5A483623",
|
||||
"propose_seq" : 0,
|
||||
"transaction_hash" : "4BC2CE596CBD1321775320E2067F9C06D3862826212C16EF42ABB6A2B0414306"
|
||||
},
|
||||
"5C29005CF4FB479FC49EEFB4A5B075C86DD963CC" : {
|
||||
"close_time" : 486082973,
|
||||
"peer_id" : "n9L81uNCaPgtUJfaHh89gmdvXKAmSt5Gdsw2g1iPWaPkAHW5Nm4C",
|
||||
"previous_ledger" : "0BB01379B51234BAAF501A71C7AB147F595460B689BB9E8252A0B87B5A483623",
|
||||
"propose_seq" : 0,
|
||||
"transaction_hash" : "4BC2CE596CBD1321775320E2067F9C06D3862826212C16EF42ABB6A2B0414306"
|
||||
},
|
||||
"EFC49EB648E557CC50A72D715249B80E071F7705" : {
|
||||
"close_time" : 486082973,
|
||||
"peer_id" : "n949f75evCHwgyP4fPVgaHqNHxUVN15PsJEZ3B3HnXPcPjcZAoy7",
|
||||
"previous_ledger" : "0BB01379B51234BAAF501A71C7AB147F595460B689BB9E8252A0B87B5A483623",
|
||||
"propose_seq" : 0,
|
||||
"transaction_hash" : "4BC2CE596CBD1321775320E2067F9C06D3862826212C16EF42ABB6A2B0414306"
|
||||
}
|
||||
},
|
||||
"previous_mseconds" : 2005,
|
||||
"previous_proposers" : 5,
|
||||
"proposers" : 5,
|
||||
"proposing" : false,
|
||||
"state" : "consensus",
|
||||
"synched" : true,
|
||||
"validating" : false
|
||||
},
|
||||
"status" : "success"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
*コマンドライン*
|
||||
|
||||
```
|
||||
Loading: "/etc/rippled.cfg"
|
||||
Connecting to 127.0.0.1:5005
|
||||
{
|
||||
"result" : {
|
||||
"info" : {
|
||||
"acquired" : {
|
||||
"4BC2CE596CBD1321775320E2067F9C06D3862826212C16EF42ABB6A2B0414306" : "acquired"
|
||||
},
|
||||
"close_granularity" : 10,
|
||||
"close_percent" : 50,
|
||||
"close_resolution" : 10,
|
||||
"close_times" : {
|
||||
"486082972" : 1,
|
||||
"486082973" : 4
|
||||
},
|
||||
"current_ms" : 1003,
|
||||
"have_time_consensus" : false,
|
||||
"ledger_seq" : 13701086,
|
||||
"our_position" : {
|
||||
"close_time" : 486082973,
|
||||
"previous_ledger" : "0BB01379B51234BAAF501A71C7AB147F595460B689BB9E8252A0B87B5A483623",
|
||||
"propose_seq" : 0,
|
||||
"transaction_hash" : "4BC2CE596CBD1321775320E2067F9C06D3862826212C16EF42ABB6A2B0414306"
|
||||
},
|
||||
"peer_positions" : {
|
||||
"0A2EAF919033A036D363D4E5610A66209DDBE8EE" : {
|
||||
"close_time" : 486082972,
|
||||
"peer_id" : "n9KiYM9CgngLvtRCQHZwgC2gjpdaZcCcbt3VboxiNFcKuwFVujzS",
|
||||
"previous_ledger" : "0BB01379B51234BAAF501A71C7AB147F595460B689BB9E8252A0B87B5A483623",
|
||||
"propose_seq" : 0,
|
||||
"transaction_hash" : "4BC2CE596CBD1321775320E2067F9C06D3862826212C16EF42ABB6A2B0414306"
|
||||
},
|
||||
"1567A8C953A86F8428C7B01641D79BBF2FD508F3" : {
|
||||
"close_time" : 486082973,
|
||||
"peer_id" : "n9LdgEtkmGB9E2h3K4Vp7iGUaKuq23Zr32ehxiU8FWY7xoxbWTSA",
|
||||
"previous_ledger" : "0BB01379B51234BAAF501A71C7AB147F595460B689BB9E8252A0B87B5A483623",
|
||||
"propose_seq" : 0,
|
||||
"transaction_hash" : "4BC2CE596CBD1321775320E2067F9C06D3862826212C16EF42ABB6A2B0414306"
|
||||
},
|
||||
"202397A81F20B44CF44EA99AF761295E5A8397D2" : {
|
||||
"close_time" : 486082973,
|
||||
"peer_id" : "n9MD5h24qrQqiyBC8aeqqCWvpiBiYQ3jxSr91uiDvmrkyHRdYLUj",
|
||||
"previous_ledger" : "0BB01379B51234BAAF501A71C7AB147F595460B689BB9E8252A0B87B5A483623",
|
||||
"propose_seq" : 0,
|
||||
"transaction_hash" : "4BC2CE596CBD1321775320E2067F9C06D3862826212C16EF42ABB6A2B0414306"
|
||||
},
|
||||
"5C29005CF4FB479FC49EEFB4A5B075C86DD963CC" : {
|
||||
"close_time" : 486082973,
|
||||
"peer_id" : "n9L81uNCaPgtUJfaHh89gmdvXKAmSt5Gdsw2g1iPWaPkAHW5Nm4C",
|
||||
"previous_ledger" : "0BB01379B51234BAAF501A71C7AB147F595460B689BB9E8252A0B87B5A483623",
|
||||
"propose_seq" : 0,
|
||||
"transaction_hash" : "4BC2CE596CBD1321775320E2067F9C06D3862826212C16EF42ABB6A2B0414306"
|
||||
},
|
||||
"EFC49EB648E557CC50A72D715249B80E071F7705" : {
|
||||
"close_time" : 486082973,
|
||||
"peer_id" : "n949f75evCHwgyP4fPVgaHqNHxUVN15PsJEZ3B3HnXPcPjcZAoy7",
|
||||
"previous_ledger" : "0BB01379B51234BAAF501A71C7AB147F595460B689BB9E8252A0B87B5A483623",
|
||||
"propose_seq" : 0,
|
||||
"transaction_hash" : "4BC2CE596CBD1321775320E2067F9C06D3862826212C16EF42ABB6A2B0414306"
|
||||
}
|
||||
},
|
||||
"previous_mseconds" : 2005,
|
||||
"previous_proposers" : 5,
|
||||
"proposers" : 5,
|
||||
"proposing" : false,
|
||||
"state" : "consensus",
|
||||
"synched" : true,
|
||||
"validating" : false
|
||||
},
|
||||
"status" : "success"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
|
||||
この応答は[標準フォーマット][]に従っており、正常に完了した場合は結果に次のフィールドが含まれています。
|
||||
|
||||
| `Field` | 型 | 説明 |
|
||||
|:--------|:-------|:----------------------------------------------------------|
|
||||
| `info` | オブジェクト | コンセンサスのデバッグで役立つ可能性のある情報。この出力は、予告なく変更される可能性があります。 |
|
||||
|
||||
`info`オブジェクトに含まれる可能性のあるフィールドについて以下に簡単に説明します。
|
||||
|
||||
| `Field` | 型 | 説明 |
|
||||
|:-----------------|:--------|:------------------------------------------------|
|
||||
| `ledger_seq` | 数値 | 現在コンセンサスプロセスにあるレジャーのシーケンス番号。 |
|
||||
| `our_position` | オブジェクト | コンセンサスプロセスにあるレジャーについてサーバーが予期する内容。 |
|
||||
| `peer_positions` | オブジェクト | コンセンサスプロセスにあるピアと各ピアが提案するレジャーバージョンのマップ。 |
|
||||
| `proposers` | 数値 | このコンセンサスプロセスに参加している信頼できるバリデータの数。信頼できるバリデータは、このサーバー構成に応じて異なります。 |
|
||||
| `synched` | ブール値 | このサーバー自体が、自分がネットワークと同期中であるとみなしているかどうか。 |
|
||||
| `state` | 文字列 | 現在進行中のコンセンサスプロセスの部分: `open`、`consensus`、`finished`、または`accepted`。 |
|
||||
|
||||
`info`の唯一のフィールドが`"consensus": "none"`である最小限の結果となることもありますが、これは正常です。これは、サーバーがコンセンサスラウンドの合間にあることを示します。
|
||||
|
||||
`consensus_info`コマンドを短い間隔で連続して数回実行すると、このコマンドの結果が大きく変化することがあります。
|
||||
|
||||
|
||||
### 考えられるエラー
|
||||
|
||||
* [汎用エラータイプ][]のすべて。
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -0,0 +1,193 @@
|
||||
# feature
|
||||
[[ソース]<br>](https://github.com/ripple/rippled/blob/master/src/ripple/rpc/handlers/Feature1.cpp "Source")
|
||||
|
||||
`feature`コマンドは、[Amendment](amendments.html)に関してこのサーバーが認識している情報（Amendmentが有効であるかどうか、サーバーが[Amendmentプロセス](amendments.html#amendmentプロセス)でこれらのAmendmentに賛成票を投じたかどうかなど）を返します。[新規: rippled 0.31.0][]
|
||||
|
||||
`feature`コマンドを使用して、Amendmentへの賛成票または反対票を投じるようにサーバーを一時的に設定できます。この変更は、サーバーの再起動後までは持続しません。Amendment投票で持続する変更を行うには`rippled.cfg`ファイルを使用します。詳細は、[Amendment投票の設定](amendments.html#amendment投票の設定)を参照してください。
|
||||
|
||||
_`feature`メソッドは、権限のないユーザーは実行できない[管理メソッド](admin-rippled-methods.html)です。_
|
||||
|
||||
### 要求フォーマット
|
||||
要求フォーマットの例:
|
||||
|
||||
<!-- MULTICODE_BLOCK_START -->
|
||||
|
||||
*WebSocket - すべてリスト*
|
||||
|
||||
```
|
||||
{
|
||||
"id": "list_all_features",
|
||||
"command": "feature"
|
||||
}
|
||||
```
|
||||
|
||||
*WebSocket - 拒否*
|
||||
|
||||
```
|
||||
{
|
||||
"id": "reject_multi_sign",
|
||||
"command": "feature",
|
||||
"feature": "4C97EBA926031A7CF7D7B36FDE3ED66DDA5421192D63DE53FFB46E43B9DC8373",
|
||||
"vetoed": true
|
||||
}
|
||||
```
|
||||
|
||||
*JSON-RPC*
|
||||
|
||||
```
|
||||
{
|
||||
"method": "feature",
|
||||
"params": [
|
||||
{
|
||||
"feature": "4C97EBA926031A7CF7D7B36FDE3ED66DDA5421192D63DE53FFB46E43B9DC8373",
|
||||
"vetoed": false
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
*コマンドライン*
|
||||
|
||||
```
|
||||
#Syntax: feature [<feature_id> [accept|reject]]
|
||||
rippled feature 4C97EBA926031A7CF7D7B36FDE3ED66DDA5421192D63DE53FFB46E43B9DC8373 accept
|
||||
```
|
||||
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
|
||||
要求には以下のパラメーターが含まれます。
|
||||
|
||||
| `Field` | 型 | 説明 |
|
||||
|:----------|:--------|:-------------------------------------------------------|
|
||||
| `feature` | 文字列 | _（省略可）_ Amendmentの一意のID（16進数）またはAmendmentの短い名前。指定されている場合は、応答が1つのAmendmentに限定されます。それ以外の場合は応答にすべてのAmendmentのリストが表示されます。 |
|
||||
| `vetoed` | ブール値 | （省略可、`feature`が指定されていない場合は無視されます）trueの場合、サーバーに対し`feature`で指定されたAmendmentに反対票を投じるように指示します。falseの場合、サーバーに対しAmendmentに賛成票を投じるように指示します。 |
|
||||
|
||||
**注記:** サーバーが新しいAmendmentの適用方法を現在認識していない場合でも、`feature`フィールドにAmendment IDを指定すれば、新しいAmendmentに賛成票を投じるようにサーバーを設定できます。たとえば、Amendmentを _確かに_ サポートする新しい`rippled`バージョンに間もなくアップグレードする予定がある場合などにこのように設定できます。
|
||||
|
||||
### 応答フォーマット
|
||||
|
||||
処理が成功した応答の例:
|
||||
|
||||
<!-- MULTICODE_BLOCK_START -->
|
||||
|
||||
*WebSocket - すべてリスト*
|
||||
|
||||
```
|
||||
{
|
||||
"id": "list_all_features",
|
||||
"status": "success",
|
||||
"type": "response",
|
||||
"result": {
|
||||
"features": {
|
||||
"42426C4D4F1009EE67080A9B7965B44656D7714D104A72F9B4369F97ABF044EE": {
|
||||
"enabled": false,
|
||||
"name": "FeeEscalation",
|
||||
"supported": true,
|
||||
"vetoed": false
|
||||
},
|
||||
"4C97EBA926031A7CF7D7B36FDE3ED66DDA5421192D63DE53FFB46E43B9DC8373": {
|
||||
"enabled": false,
|
||||
"name": "MultiSign",
|
||||
"supported": true,
|
||||
"vetoed": false
|
||||
},
|
||||
"6781F8368C4771B83E8B821D88F580202BCB4228075297B19E4FDC5233F1EFDC": {
|
||||
"enabled": false,
|
||||
"name": "TrustSetAuth",
|
||||
"supported": true,
|
||||
"vetoed": false
|
||||
},
|
||||
"C1B8D934087225F509BEB5A8EC24447854713EE447D277F69545ABFA0E0FD490": {
|
||||
"enabled": false,
|
||||
"name": "Tickets",
|
||||
"supported": true,
|
||||
"vetoed": false
|
||||
},
|
||||
"DA1BD556B42D85EA9C84066D028D355B52416734D3283F85E216EA5DA6DB7E13": {
|
||||
"enabled": false,
|
||||
"name": "SusPay",
|
||||
"supported": true,
|
||||
"vetoed": false
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
*WebSocket - 拒否*
|
||||
|
||||
```
|
||||
{
|
||||
"id": "reject_multi_sign",
|
||||
"status": "success",
|
||||
"type": "response",
|
||||
"result": {
|
||||
"features": {
|
||||
"4C97EBA926031A7CF7D7B36FDE3ED66DDA5421192D63DE53FFB46E43B9DC8373": {
|
||||
"enabled": false,
|
||||
"name": "MultiSign",
|
||||
"supported": true,
|
||||
"vetoed": true
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
*JSON-RPC*
|
||||
|
||||
```
|
||||
200 OK
|
||||
{
|
||||
"result": {
|
||||
"4C97EBA926031A7CF7D7B36FDE3ED66DDA5421192D63DE53FFB46E43B9DC8373": {
|
||||
"enabled": false,
|
||||
"name": "MultiSign",
|
||||
"supported": true,
|
||||
"vetoed": false
|
||||
},
|
||||
"status": "success"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
*コマンドライン*
|
||||
|
||||
```
|
||||
Loading: "/etc/rippled.cfg"
|
||||
Connecting to 127.0.0.1:5005
|
||||
{
|
||||
"result": {
|
||||
"4C97EBA926031A7CF7D7B36FDE3ED66DDA5421192D63DE53FFB46E43B9DC8373": {
|
||||
"enabled": false,
|
||||
"name": "MultiSign",
|
||||
"supported": true,
|
||||
"vetoed": false
|
||||
},
|
||||
"status": "success"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
|
||||
応答は[標準フォーマット][]に従っており、正常に完了した場合は結果に**Amendmentのマップ**がJSONプロジェクトとして含まれています。オブジェクトのキーはAmendment IDです。各キーの値は、そのIDのAmendmentのステータスを記述した _Amendmentオブジェクト_ です。要求に`feature`が指定されいる場合、要求による変更の適用後には、要求されたAmendmentオブジェクトだけがマップに含まれます。各Amendmentオブジェクトのフィールドを次に示します。
|
||||
|
||||
| `Field` | 型 | 説明 |
|
||||
|:------------|:--------|:-----------------------------------------------------|
|
||||
| `enabled` | ブール値 | 最新レジャーでこのAmendmentが現在有効であるかどうか。 |
|
||||
| `name` | 文字列 | （省略される場合があります）このAmendmentの人間が読める形式の名前（判明している場合）。 |
|
||||
| `supported` | ブール値 | サーバーがこのAmendmentの適用方法を認識しているかどうか。このフィールドが`false`（サーバーがこのAmendmentの適用方法を認識していない）に設定されており、`enabled`が`true`（このAmendmentが最新レジャーで有効である）に設定されている場合、このAmendmentによりサーバーが[Amendment blocked](amendments.html#amendment-blocked)になる可能性があります。 |
|
||||
| `vetoed` | ブール値 | サーバーがこのAmendmentに反対票を投じるように指示されているかどうか。 |
|
||||
|
||||
**注意:** Amendmentの`name`は、Amendmentの内容を厳密に示すものではありません。サーバー間でこの名前が一意であることや整合性があることは保証されません。
|
||||
|
||||
### 考えられるエラー
|
||||
|
||||
* [汎用エラータイプ][]のすべて。
|
||||
* `badFeature` - 指定されている`feature`のフォーマットが正しくないか、サーバーがその名前のAmendmentを認識していません。
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -0,0 +1,161 @@
|
||||
# fetch_info
|
||||
[[ソース]<br>](https://github.com/ripple/rippled/blob/315a8b6b602798a4cff4d8e1911936011e12abdb/src/ripple/rpc/handlers/FetchInfo.cpp "Source")
|
||||
|
||||
`fetch_info`コマンドは、このサーバーが現在ネットワークからフェッチしているオブジェクトに関する情報と、その情報を所有しているピアの数を返します。これは現在の取得操作をリセットする場合にも使用できます。
|
||||
|
||||
_`fetch_info`メソッドは、権限のないユーザーは実行できない[管理メソッド](admin-rippled-methods.html)です。_
|
||||
|
||||
### 要求フォーマット
|
||||
要求フォーマットの例:
|
||||
|
||||
<!-- MULTICODE_BLOCK_START -->
|
||||
|
||||
*WebSocket*
|
||||
|
||||
```
|
||||
{
|
||||
"id": 91,
|
||||
"command": "fetch_info",
|
||||
"clear": false
|
||||
}
|
||||
```
|
||||
|
||||
*JSON-RPC*
|
||||
|
||||
```
|
||||
{
|
||||
"method": "fetch_info",
|
||||
"params": [
|
||||
{
|
||||
"clear": false
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
*コマンドライン*
|
||||
|
||||
```
|
||||
#Syntax: fetch_info [clear]
|
||||
rippled fetch_info
|
||||
```
|
||||
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
|
||||
要求には以下のパラメーターが含まれます。
|
||||
|
||||
| `Field` | 型 | 説明 |
|
||||
|:--------|:--------|:---------------------------------------------------------|
|
||||
| `clear` | ブール値 | `true`の場合、現在のフェッチ操作がリセットされます。それ以外の場合、進行中のフェッチ操作のステータスのみが取得されます。 |
|
||||
|
||||
### 応答フォーマット
|
||||
|
||||
処理が成功した応答の例:
|
||||
|
||||
<!-- MULTICODE_BLOCK_START -->
|
||||
|
||||
*JSON-RPC*
|
||||
|
||||
```
|
||||
{
|
||||
"result" : {
|
||||
"info" : {
|
||||
"348928" : {
|
||||
"hash" : "C26D432B06F84861BCACD7942EDC3FE0B2E1DEB966A9E516A0FD275A375C2010",
|
||||
"have_header" : true,
|
||||
"have_state" : false,
|
||||
"have_transactions" : true,
|
||||
"needed_state_hashes" : [
|
||||
"BF8DC6B1E10D1D3565BF0649075D22EBFD34F751AFCC0E53E81D74786BC88922",
|
||||
"34E37A71CB51A12C73A435250E6A6349F7884C7EEBA6B88FA31F0244E967E88F",
|
||||
"BFB7D3008A7D61FD6A0538D1C2E70CFB94CE8DC66606319C372F278A48629765",
|
||||
"41C0C61D701FB1EA586F0EF1FC7A91FEC476D979589DA60507F05C13F7C21975",
|
||||
"6DDE8840A2C3C7FF05E5FFEE4D06408694C16A8357338FE0C4581DC3D8A00BBA",
|
||||
"6C69D833B582C849917806FA009518832BB50E900E43716FD7CC1966428DD0CF",
|
||||
"1EDC020CFC4AF19B625C52E20B66D6AE672821CCC461E8A9C457A3B2955657F7",
|
||||
"FC0616A66A2B0589CA513F3341D4EA51E782C4601E5072308478E3CC19264640",
|
||||
"19FC607B5DE1B64681A676EC1ED5507B9555B0E098CD9D898320297DE1A64033",
|
||||
"5E128D3FC990074E35687387A14AA12D9FD287E5AB57CB9B2FD83DE635DF5CA9",
|
||||
"DE72820F3981770F2AA8770BC233B80661F1A452819D8529008875FF8DED87A9",
|
||||
"3ACB84BEE2C45556351FF60FD787D235C9CF5623FB8A35B01446B773598E7CC0",
|
||||
"0DD3A8DF69874148057F1F2BF305442FF2E89A76A08B4CC8C051E2ED69B874F3",
|
||||
"4AE9A9C4F12A5BD0355037DA40A0B145420A2168A9FEDE43E643BD13062F8ECE",
|
||||
"08CBF8CFFEC207F5AC4E4F24BC447011FD8C79D25B344281FBFB4732D7058ED4",
|
||||
"779B2577C5C4BAED6657421448EA506BBF50F86BE363E0924127C4EA17A58BBE"
|
||||
],
|
||||
"peers" : 2,
|
||||
"timeouts" : 0
|
||||
}
|
||||
},
|
||||
"status" : "success"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
*コマンドライン*
|
||||
|
||||
```
|
||||
Loading: "/etc/rippled.cfg"
|
||||
Connecting to 127.0.0.1:5005
|
||||
{
|
||||
"result" : {
|
||||
"info" : {
|
||||
"348928" : {
|
||||
"hash" : "C26D432B06F84861BCACD7942EDC3FE0B2E1DEB966A9E516A0FD275A375C2010",
|
||||
"have_header" : true,
|
||||
"have_state" : false,
|
||||
"have_transactions" : true,
|
||||
"needed_state_hashes" : [
|
||||
"BF8DC6B1E10D1D3565BF0649075D22EBFD34F751AFCC0E53E81D74786BC88922",
|
||||
"34E37A71CB51A12C73A435250E6A6349F7884C7EEBA6B88FA31F0244E967E88F",
|
||||
"BFB7D3008A7D61FD6A0538D1C2E70CFB94CE8DC66606319C372F278A48629765",
|
||||
"41C0C61D701FB1EA586F0EF1FC7A91FEC476D979589DA60507F05C13F7C21975",
|
||||
"6DDE8840A2C3C7FF05E5FFEE4D06408694C16A8357338FE0C4581DC3D8A00BBA",
|
||||
"6C69D833B582C849917806FA009518832BB50E900E43716FD7CC1966428DD0CF",
|
||||
"1EDC020CFC4AF19B625C52E20B66D6AE672821CCC461E8A9C457A3B2955657F7",
|
||||
"FC0616A66A2B0589CA513F3341D4EA51E782C4601E5072308478E3CC19264640",
|
||||
"19FC607B5DE1B64681A676EC1ED5507B9555B0E098CD9D898320297DE1A64033",
|
||||
"5E128D3FC990074E35687387A14AA12D9FD287E5AB57CB9B2FD83DE635DF5CA9",
|
||||
"DE72820F3981770F2AA8770BC233B80661F1A452819D8529008875FF8DED87A9",
|
||||
"3ACB84BEE2C45556351FF60FD787D235C9CF5623FB8A35B01446B773598E7CC0",
|
||||
"0DD3A8DF69874148057F1F2BF305442FF2E89A76A08B4CC8C051E2ED69B874F3",
|
||||
"4AE9A9C4F12A5BD0355037DA40A0B145420A2168A9FEDE43E643BD13062F8ECE",
|
||||
"08CBF8CFFEC207F5AC4E4F24BC447011FD8C79D25B344281FBFB4732D7058ED4",
|
||||
"779B2577C5C4BAED6657421448EA506BBF50F86BE363E0924127C4EA17A58BBE"
|
||||
],
|
||||
"peers" : 2,
|
||||
"timeouts" : 0
|
||||
}
|
||||
},
|
||||
"status" : "success"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
|
||||
この応答は[標準フォーマット][]に従っており、正常に完了した場合は結果に次のフィールドが含まれています。
|
||||
|
||||
| `Field` | 型 | 説明 |
|
||||
|:--------|:-------|:----------------------------------------------------------|
|
||||
| `info` | オブジェクト | フェッチ対象のオブジェクトと、そのフェッチ対象オブジェクトのステータスのマップ。フェッチ対象のレジャーはそのシーケンス番号によって識別されます。フェッチ対象のレジャーとその他のオブジェクトがハッシュによって識別されることもあります。 |
|
||||
|
||||
進行中のフェッチ操作を記述するフィールドは、予告なく変更される可能性があります。以下のフィールドが含まれている可能性があります。
|
||||
|
||||
| `Field` | 型 | 説明 |
|
||||
|:----------------------|:------------------------|:---------------------------|
|
||||
| `hash` | 文字列 | フェッチ対象アイテムのハッシュ。 |
|
||||
| `have_header` | ブール値 | レジャーの場合、このサーバーがすでにレジャーのヘッダーセクションを取得しているかどうか。 |
|
||||
| `have_transactions` | ブール値 | レジャーの場合、このサーバーがすでにレジャーのトランザクションセクションを取得しているかどうか。 |
|
||||
| `needed_state_hashes` | （ハッシュ）文字列の配列 | まだ必要とされる、このアイテムの状態オブジェクトのハッシュ値。必要なハッシュの数が16を超えている場合、応答には最初の16個のハッシュのみが含まれます。 |
|
||||
| `peers` | 数値 | このアイテムが利用可能であるピアの数。 |
|
||||
| `timeouts` | 数値 | このアイテムをフェッチしようとしてタイムアウトになった（2.5秒）回数。 |
|
||||
|
||||
### 考えられるエラー
|
||||
|
||||
* [汎用エラータイプ][]のすべて。
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -0,0 +1,153 @@
|
||||
# get_counts
|
||||
[[ソース]<br>](https://github.com/ripple/rippled/blob/c7118a183a660648aa88a3546a6b2c5bce858440/src/ripple/rpc/handlers/GetCounts.cpp "Source")
|
||||
|
||||
`get_counts`コマンドは、サーバーの健全性に関するさまざまな統計情報を提供します。そのほとんどは、現在メモリーに格納されている各種オブジェクトの数です。
|
||||
|
||||
_`get_counts`メソッドは、権限のないユーザーは実行できない[管理メソッド](admin-rippled-methods.html)です。_
|
||||
|
||||
### 要求フォーマット
|
||||
要求フォーマットの例:
|
||||
|
||||
<!-- MULTICODE_BLOCK_START -->
|
||||
|
||||
*WebSocket*
|
||||
|
||||
```
|
||||
{
|
||||
"id": 90,
|
||||
"command": "get_counts",
|
||||
"min_count": 100
|
||||
}
|
||||
```
|
||||
|
||||
*JSON-RPC*
|
||||
|
||||
```
|
||||
{
|
||||
"method": "get_counts",
|
||||
"params": [
|
||||
{
|
||||
"min_count": 100
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
*コマンドライン*
|
||||
|
||||
```
|
||||
#Syntax: get_counts [min_count]
|
||||
rippled get_counts 100
|
||||
```
|
||||
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
|
||||
要求には以下のパラメーターが含まれます。
|
||||
|
||||
| `Field` | 型 | 説明 |
|
||||
|:------------|:--------------------------|:-----------------------------------|
|
||||
| `min_count` | 数値（符号なし整数） | この値以上の値を含むフィールドのみを返します。 |
|
||||
|
||||
### 応答フォーマット
|
||||
|
||||
処理が成功した応答の例:
|
||||
|
||||
<!-- MULTICODE_BLOCK_START -->
|
||||
|
||||
*JSON-RPC*
|
||||
|
||||
```
|
||||
{
|
||||
"result" : {
|
||||
"AL_hit_rate" : 48.36725616455078,
|
||||
"HashRouterEntry" : 3048,
|
||||
"Ledger" : 46,
|
||||
"NodeObject" : 10417,
|
||||
"SLE_hit_rate" : 64.62035369873047,
|
||||
"STArray" : 1299,
|
||||
"STLedgerEntry" : 646,
|
||||
"STObject" : 6987,
|
||||
"STTx" : 4104,
|
||||
"STValidation" : 610,
|
||||
"Transaction" : 4069,
|
||||
"dbKBLedger" : 10733,
|
||||
"dbKBTotal" : 39069,
|
||||
"dbKBTransaction" : 26982,
|
||||
"fullbelow_size" : 0,
|
||||
"historical_perminute" : 0,
|
||||
"ledger_hit_rate" : 71.0565185546875,
|
||||
"node_hit_rate" : 3.808214902877808,
|
||||
"node_read_bytes" : 393611911,
|
||||
"node_reads_hit" : 1283098,
|
||||
"node_reads_total" : 679410,
|
||||
"node_writes" : 1744285,
|
||||
"node_written_bytes" : 794368909,
|
||||
"status" : "success",
|
||||
"treenode_cache_size" : 6650,
|
||||
"treenode_track_size" : 598631,
|
||||
"uptime" : "3 hours, 50 minutes, 27 seconds",
|
||||
"write_load" : 0
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
*コマンドライン*
|
||||
|
||||
```
|
||||
Loading: "/etc/rippled.cfg"
|
||||
Connecting to 127.0.0.1:5005
|
||||
{
|
||||
"result" : {
|
||||
"AL_hit_rate" : 48.36725616455078,
|
||||
"HashRouterEntry" : 3048,
|
||||
"Ledger" : 46,
|
||||
"NodeObject" : 10417,
|
||||
"SLE_hit_rate" : 64.62035369873047,
|
||||
"STArray" : 1299,
|
||||
"STLedgerEntry" : 646,
|
||||
"STObject" : 6987,
|
||||
"STTx" : 4104,
|
||||
"STValidation" : 610,
|
||||
"Transaction" : 4069,
|
||||
"dbKBLedger" : 10733,
|
||||
"dbKBTotal" : 39069,
|
||||
"dbKBTransaction" : 26982,
|
||||
"fullbelow_size" : 0,
|
||||
"historical_perminute" : 0,
|
||||
"ledger_hit_rate" : 71.0565185546875,
|
||||
"node_hit_rate" : 3.808214902877808,
|
||||
"node_read_bytes" : 393611911,
|
||||
"node_reads_hit" : 1283098,
|
||||
"node_reads_total" : 679410,
|
||||
"node_writes" : 1744285,
|
||||
"node_written_bytes" : 794368909,
|
||||
"status" : "success",
|
||||
"treenode_cache_size" : 6650,
|
||||
"treenode_track_size" : 598631,
|
||||
"uptime" : "3 hours, 50 minutes, 27 seconds",
|
||||
"write_load" : 0
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
|
||||
応答は[標準フォーマット][]に従っています。結果に含まれるフィールドのリストは、予告なく変更される可能性がありますが、（特に）以下のいずれかが含まれます。
|
||||
|
||||
| `Field` | 型 | 説明 |
|
||||
|:--------------|:-------|:----------------------------------------------------|
|
||||
| `Transaction` | 数値 | メモリー内の`Transaction`オブジェクトの数 |
|
||||
| `Ledger` | 数値 | メモリー内のレジャーの数 |
|
||||
| `uptime` | 文字列 | このサーバーの連続稼働時間。 |
|
||||
|
||||
その他のほとんどのエントリーでは、値はメモリー内に現在保持されている当該タイプのオブジェクトの数を示します。
|
||||
|
||||
### 考えられるエラー
|
||||
|
||||
* [汎用エラータイプ][]のすべて。
|
||||
* `invalidParams` - 1つ以上のフィールドの指定が正しくないか、1つ以上の必須フィールドが指定されていません。
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -0,0 +1,414 @@
|
||||
# peers
|
||||
[[ソース]<br>](https://github.com/ripple/rippled/blob/52f298f150fc1530d201d3140c80d3eaf781cb5f/src/ripple/rpc/handlers/Peers.cpp "Source")
|
||||
|
||||
`peers`コマンドは、[ピアプロトコル](peer-protocol.html)でこのサーバーに現在接続されているその他のすべての`rippled`サーバーのリスト（各サーバーの接続状況と同期状況を含む）を返します。
|
||||
|
||||
*`peers`要求は、権限のないユーザーは実行できない[管理メソッド](admin-rippled-methods.html)です。*
|
||||
|
||||
### 要求フォーマット
|
||||
要求フォーマットの例:
|
||||
|
||||
<!-- MULTICODE_BLOCK_START -->
|
||||
|
||||
*WebSocket*
|
||||
|
||||
```
|
||||
{
|
||||
"id": 2,
|
||||
"command": "peers"
|
||||
}
|
||||
```
|
||||
|
||||
*コマンドライン*
|
||||
|
||||
```
|
||||
rippled peers
|
||||
```
|
||||
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
|
||||
この要求には追加パラメーターはありません。
|
||||
|
||||
### 応答フォーマット
|
||||
|
||||
処理が成功した応答の例:
|
||||
|
||||
<!-- MULTICODE_BLOCK_START -->
|
||||
|
||||
*WebSocket*
|
||||
|
||||
```
|
||||
{
|
||||
"id": 2,
|
||||
"status": "success",
|
||||
"type": "response",
|
||||
"result": {
|
||||
"cluster": {},
|
||||
"peers": [
|
||||
{
|
||||
"address": "184.172.237.226:51235",
|
||||
"complete_ledgers": "14534883 - 18828973",
|
||||
"latency": 117,
|
||||
"ledger": "50A2577CE6EB8A92847C443BDA45F5C5F0A22B9C6F4B47DBA0C12BDA75001D01",
|
||||
"load": 54,
|
||||
"public_key": "n9KNYm52mgcUQ7R2RA4kyw9Nk1yc6S35PaiuyqjYsy6UjhCXpw12",
|
||||
"uptime": 55036,
|
||||
"version": "rippled-0.30.0-hf1"
|
||||
},
|
||||
{
|
||||
"address": "54.186.248.91:51235",
|
||||
"complete_ledgers": "18827949 - 18828973",
|
||||
"latency": 91,
|
||||
"ledger": "50A2577CE6EB8A92847C443BDA45F5C5F0A22B9C6F4B47DBA0C12BDA75001D01",
|
||||
"load": 62,
|
||||
"public_key": "n9MT5EjnV912KGuBUqPs4tpdhzMPGcnDBrTuWkD9sWQHJ1kDcUcz",
|
||||
"uptime": 83814,
|
||||
"version": "rippled-0.30.1"
|
||||
},
|
||||
{
|
||||
"address": "54.84.21.230:51235",
|
||||
"complete_ledgers": "18827949 - 18828973",
|
||||
"latency": 202,
|
||||
"ledger": "50A2577CE6EB8A92847C443BDA45F5C5F0A22B9C6F4B47DBA0C12BDA75001D01",
|
||||
"load": 60,
|
||||
"public_key": "n9KJb7NMxGySRcjCqh69xEPMUhwJx22qntYYXsnUqYgjsJhNoW7g",
|
||||
"uptime": 99625,
|
||||
"version": "rippled-0.30.1"
|
||||
},
|
||||
{
|
||||
"address": "72.251.233.162:51235",
|
||||
"complete_ledgers": "18827949 - 18828973",
|
||||
"latency": 36,
|
||||
"ledger": "50A2577CE6EB8A92847C443BDA45F5C5F0A22B9C6F4B47DBA0C12BDA75001D01",
|
||||
"load": 66,
|
||||
"public_key": "n9M8RSk6hrvXZKFQ6CxPbJsjt73xW1xsnjn7G69VAMbE2j4sBQNQ",
|
||||
"uptime": 99619,
|
||||
"version": "rippled-0.30.1"
|
||||
},
|
||||
{
|
||||
"address": "162.217.98.136:51235",
|
||||
"complete_ledgers": "32570 - 18828973",
|
||||
"latency": 118,
|
||||
"ledger": "50A2577CE6EB8A92847C443BDA45F5C5F0A22B9C6F4B47DBA0C12BDA75001D01",
|
||||
"load": 69,
|
||||
"public_key": "n944PcXEoZaiEHnwFD92xA4bxsS7jjYb27WcdDQwkHYyk1MWTEsX",
|
||||
"uptime": 99625,
|
||||
"version": "rippled-0.30.1"
|
||||
},
|
||||
{
|
||||
"address": "72.251.233.163:51235",
|
||||
"complete_ledgers": "18827949 - 18828973",
|
||||
"latency": 51,
|
||||
"ledger": "50A2577CE6EB8A92847C443BDA45F5C5F0A22B9C6F4B47DBA0C12BDA75001D01",
|
||||
"load": 61,
|
||||
"public_key": "n94ne2Z5dX8qcJNa8cPtAbtn21gEaCoEduS8TwdGAhi1iLfCUMDm",
|
||||
"uptime": 99625,
|
||||
"version": "rippled-0.30.1"
|
||||
},
|
||||
{
|
||||
"address": "54.186.73.52:51235",
|
||||
"complete_ledgers": "18827949 - 18828973",
|
||||
"latency": 72,
|
||||
"ledger": "50A2577CE6EB8A92847C443BDA45F5C5F0A22B9C6F4B47DBA0C12BDA75001D01",
|
||||
"load": 60,
|
||||
"public_key": "n9JySgyBVcQKvyDoeRKg7s2Mm6ZcFHk22vUZb3o1HSosWxcj9xPt",
|
||||
"uptime": 99625,
|
||||
"version": "rippled-0.30.1"
|
||||
},
|
||||
{
|
||||
"address": "72.251.233.165:51235",
|
||||
"complete_ledgers": "18827949 - 18828973",
|
||||
"latency": 40,
|
||||
"ledger": "50A2577CE6EB8A92847C443BDA45F5C5F0A22B9C6F4B47DBA0C12BDA75001D01",
|
||||
"load": 63,
|
||||
"public_key": "n9M77Uc9CSaSFZqt5V7sxPR4kFwbha7hwUFBD5v5kZt2SQjBeoDs",
|
||||
"uptime": 99625,
|
||||
"version": "rippled-0.30.1"
|
||||
},
|
||||
{
|
||||
"address": "72.251.232.173:51235",
|
||||
"complete_ledgers": "32570 - 18828973",
|
||||
"latency": 40,
|
||||
"ledger": "50A2577CE6EB8A92847C443BDA45F5C5F0A22B9C6F4B47DBA0C12BDA75001D01",
|
||||
"load": 71,
|
||||
"public_key": "n9JveA1hHDGjZECaYC7KM4JP8NXXzNXAxixbzcLTGnrsFZsA9AD1",
|
||||
"uptime": 99625,
|
||||
"version": "rippled-0.31.0-b6"
|
||||
},
|
||||
{
|
||||
"address": "98.167.120.212:51235",
|
||||
"complete_ledgers": "18828845 - 18828973",
|
||||
"latency": 99,
|
||||
"ledger": "50A2577CE6EB8A92847C443BDA45F5C5F0A22B9C6F4B47DBA0C12BDA75001D01",
|
||||
"load": 60,
|
||||
"public_key": "n9LDBRoqPYY7RdkNXbX1dqZXVtUKcSqzs2CZPhTH7ymA9X7Xzmpj",
|
||||
"uptime": 99625,
|
||||
"version": "rippled-0.30.1-rc4"
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
*JSON-RPC*
|
||||
|
||||
```
|
||||
{
|
||||
"result" : {
|
||||
"cluster" : {},
|
||||
"peers" : [
|
||||
{
|
||||
"address" : "184.172.237.226:51235",
|
||||
"complete_ledgers" : "14535005 - 18828957",
|
||||
"latency" : 114,
|
||||
"ledger" : "80FCB89BC5B90D2B9C2CE33786738809796F04FB9CB1E5EEE768DD9A9C399FB0",
|
||||
"load" : 47,
|
||||
"public_key" : "n9KNYm52mgcUQ7R2RA4kyw9Nk1yc6S35PaiuyqjYsy6UjhCXpw12",
|
||||
"uptime" : 54976,
|
||||
"version" : "rippled-0.30.0-hf1"
|
||||
},
|
||||
{
|
||||
"address" : "54.186.248.91:51235",
|
||||
"complete_ledgers" : "18827934 - 18828958",
|
||||
"latency" : 68,
|
||||
"ledger" : "9447480E351221123B1A454356435A66C188D9794B0197A060637E19F074B421",
|
||||
"load" : 56,
|
||||
"public_key" : "n9MT5EjnV912KGuBUqPs4tpdhzMPGcnDBrTuWkD9sWQHJ1kDcUcz",
|
||||
"uptime" : 83754,
|
||||
"version" : "rippled-0.30.1"
|
||||
},
|
||||
{
|
||||
"address" : "54.84.21.230:51235",
|
||||
"complete_ledgers" : "18827934 - 18828958",
|
||||
"latency" : 135,
|
||||
"ledger" : "9447480E351221123B1A454356435A66C188D9794B0197A060637E19F074B421",
|
||||
"load" : 54,
|
||||
"public_key" : "n9KJb7NMxGySRcjCqh69xEPMUhwJx22qntYYXsnUqYgjsJhNoW7g",
|
||||
"uptime" : 99565,
|
||||
"version" : "rippled-0.30.1"
|
||||
},
|
||||
{
|
||||
"address" : "72.251.233.162:51235",
|
||||
"complete_ledgers" : "18827934 - 18828958",
|
||||
"latency" : 24,
|
||||
"ledger" : "9447480E351221123B1A454356435A66C188D9794B0197A060637E19F074B421",
|
||||
"load" : 61,
|
||||
"public_key" : "n9M8RSk6hrvXZKFQ6CxPbJsjt73xW1xsnjn7G69VAMbE2j4sBQNQ",
|
||||
"uptime" : 99560,
|
||||
"version" : "rippled-0.30.1"
|
||||
},
|
||||
{
|
||||
"address" : "162.217.98.136:51235",
|
||||
"complete_ledgers" : "32570 - 18828958",
|
||||
"latency" : 88,
|
||||
"ledger" : "9447480E351221123B1A454356435A66C188D9794B0197A060637E19F074B421",
|
||||
"load" : 55,
|
||||
"public_key" : "n944PcXEoZaiEHnwFD92xA4bxsS7jjYb27WcdDQwkHYyk1MWTEsX",
|
||||
"uptime" : 99566,
|
||||
"version" : "rippled-0.30.1"
|
||||
},
|
||||
{
|
||||
"address" : "72.251.233.163:51235",
|
||||
"complete_ledgers" : "18827934 - 18828958",
|
||||
"latency" : 24,
|
||||
"ledger" : "9447480E351221123B1A454356435A66C188D9794B0197A060637E19F074B421",
|
||||
"load" : 56,
|
||||
"public_key" : "n94ne2Z5dX8qcJNa8cPtAbtn21gEaCoEduS8TwdGAhi1iLfCUMDm",
|
||||
"uptime" : 99566,
|
||||
"version" : "rippled-0.30.1"
|
||||
},
|
||||
{
|
||||
"address" : "54.186.73.52:51235",
|
||||
"complete_ledgers" : "18827934 - 18828958",
|
||||
"latency" : 51,
|
||||
"ledger" : "9447480E351221123B1A454356435A66C188D9794B0197A060637E19F074B421",
|
||||
"load" : 56,
|
||||
"public_key" : "n9JySgyBVcQKvyDoeRKg7s2Mm6ZcFHk22vUZb3o1HSosWxcj9xPt",
|
||||
"uptime" : 99566,
|
||||
"version" : "rippled-0.30.1"
|
||||
},
|
||||
{
|
||||
"address" : "72.251.233.165:51235",
|
||||
"complete_ledgers" : "18827934 - 18828958",
|
||||
"latency" : 25,
|
||||
"ledger" : "9447480E351221123B1A454356435A66C188D9794B0197A060637E19F074B421",
|
||||
"load" : 56,
|
||||
"public_key" : "n9M77Uc9CSaSFZqt5V7sxPR4kFwbha7hwUFBD5v5kZt2SQjBeoDs",
|
||||
"uptime" : 99566,
|
||||
"version" : "rippled-0.30.1"
|
||||
},
|
||||
{
|
||||
"address" : "72.251.232.173:51235",
|
||||
"complete_ledgers" : "32570 - 18828958",
|
||||
"latency" : 24,
|
||||
"ledger" : "9447480E351221123B1A454356435A66C188D9794B0197A060637E19F074B421",
|
||||
"load" : 81,
|
||||
"public_key" : "n9JveA1hHDGjZECaYC7KM4JP8NXXzNXAxixbzcLTGnrsFZsA9AD1",
|
||||
"uptime" : 99566,
|
||||
"version" : "rippled-0.31.0-b6"
|
||||
},
|
||||
{
|
||||
"address" : "98.167.120.212:51235",
|
||||
"complete_ledgers" : "18828830 - 18828957",
|
||||
"latency" : 137,
|
||||
"ledger" : "9447480E351221123B1A454356435A66C188D9794B0197A060637E19F074B421",
|
||||
"load" : 54,
|
||||
"public_key" : "n9LDBRoqPYY7RdkNXbX1dqZXVtUKcSqzs2CZPhTH7ymA9X7Xzmpj",
|
||||
"uptime" : 99566,
|
||||
"version" : "rippled-0.30.1-rc4"
|
||||
}
|
||||
],
|
||||
"status" : "success"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
*コマンドライン*
|
||||
|
||||
```
|
||||
Loading: "/etc/rippled.cfg"
|
||||
Connecting to 127.0.0.1:5005
|
||||
{
|
||||
"result" : {
|
||||
"cluster" : {},
|
||||
"peers" : [
|
||||
{
|
||||
"address" : "72.251.232.173:51235",
|
||||
"complete_ledgers" : "32570 - 18851276",
|
||||
"latency" : 22,
|
||||
"ledger" : "592C723DDBB1C5119F0D8288894060C83C8C2975A061D7C9971427D6798098F5",
|
||||
"load" : 20,
|
||||
"public_key" : "n9JveA1hHDGjZECaYC7KM4JP8NXXzNXAxixbzcLTGnrsFZsA9AD1",
|
||||
"uptime" : 26,
|
||||
"version" : "rippled-0.31.0-b6"
|
||||
},
|
||||
{
|
||||
"address" : "169.53.155.36:51235",
|
||||
"complete_ledgers" : "12920801 - 18851275",
|
||||
"latency" : 127,
|
||||
"load" : 16,
|
||||
"public_key" : "n9L42gouyppsmsMXXUdByXnVDUZv1eu6KLZUWUkNHsukzv3pr7po",
|
||||
"uptime" : 18,
|
||||
"version" : "rippled-0.30.0-hf1"
|
||||
},
|
||||
{
|
||||
"address" : "169.53.155.44:51235",
|
||||
"complete_ledgers" : "12920779 - 18851276",
|
||||
"latency" : 20,
|
||||
"ledger" : "592C723DDBB1C5119F0D8288894060C83C8C2975A061D7C9971427D6798098F5",
|
||||
"load" : 49,
|
||||
"public_key" : "n94BpoEqEf1PxpAv3Bmyy2WoKHyeMpHPH4tcj6P9NW98zdzEyRhi",
|
||||
"uptime" : 50,
|
||||
"version" : "rippled-0.30.0-hf1"
|
||||
},
|
||||
{
|
||||
"address" : "192.170.145.77:51235",
|
||||
"complete_ledgers" : "32570 - 18851277",
|
||||
"latency" : 145,
|
||||
"ledger" : "592C723DDBB1C5119F0D8288894060C83C8C2975A061D7C9971427D6798098F5",
|
||||
"load" : 29,
|
||||
"public_key" : "n9LwcmtjDAJQz4u8DZCMGQ9GXHuMEV4Cf8KpPL9NgqAV2puxdYc2",
|
||||
"uptime" : 51,
|
||||
"version" : "rippled-0.30.1"
|
||||
},
|
||||
{
|
||||
"address" : "162.217.98.136:51235",
|
||||
"complete_ledgers" : "32570 - 18851277",
|
||||
"latency" : 83,
|
||||
"ledger" : "592C723DDBB1C5119F0D8288894060C83C8C2975A061D7C9971427D6798098F5",
|
||||
"load" : 30,
|
||||
"public_key" : "n944PcXEoZaiEHnwFD92xA4bxsS7jjYb27WcdDQwkHYyk1MWTEsX",
|
||||
"uptime" : 50,
|
||||
"version" : "rippled-0.30.1"
|
||||
},
|
||||
{
|
||||
"address" : "184.172.237.241:51235",
|
||||
"complete_ledgers" : "14153089 - 18851277",
|
||||
"latency" : 104,
|
||||
"ledger" : "592C723DDBB1C5119F0D8288894060C83C8C2975A061D7C9971427D6798098F5",
|
||||
"load" : 29,
|
||||
"public_key" : "n9L3LdCTVYUhCKtQtxiHrQ5ocNXVqZFiEJpF5pX9DXahYLrvi5R7",
|
||||
"uptime" : 51,
|
||||
"version" : "rippled-0.30.0-hf1"
|
||||
},
|
||||
{
|
||||
"address" : "99.110.49.91:51301",
|
||||
"complete_ledgers" : "32570 - 18851277",
|
||||
"latency" : 152,
|
||||
"ledger" : "592C723DDBB1C5119F0D8288894060C83C8C2975A061D7C9971427D6798098F5",
|
||||
"load" : 55,
|
||||
"public_key" : "n9LGv3xKVqhxq6vcTfmJZhxyhjywsZbvJvpFbZRXzzz5uQ64xTLy",
|
||||
"uptime" : 51,
|
||||
"version" : "rippled-0.31.0-b6"
|
||||
},
|
||||
{
|
||||
"address" : "169.53.155.45:51235",
|
||||
"complete_ledgers" : "12920779 - 18851277",
|
||||
"latency" : 15,
|
||||
"ledger" : "592C723DDBB1C5119F0D8288894060C83C8C2975A061D7C9971427D6798098F5",
|
||||
"load" : 30,
|
||||
"public_key" : "n9MRiHyMk43YpqATWeT8Zyu4HJq1btb5oNKmnHTkLJKQg9LQQq3v",
|
||||
"uptime" : 51,
|
||||
"version" : "rippled-0.30.0-hf1"
|
||||
},
|
||||
{
|
||||
"address" : "54.186.248.91:51235",
|
||||
"complete_ledgers" : "18850253 - 18851277",
|
||||
"latency" : 63,
|
||||
"ledger" : "592C723DDBB1C5119F0D8288894060C83C8C2975A061D7C9971427D6798098F5",
|
||||
"load" : 36,
|
||||
"public_key" : "n9MT5EjnV912KGuBUqPs4tpdhzMPGcnDBrTuWkD9sWQHJ1kDcUcz",
|
||||
"uptime" : 51,
|
||||
"version" : "rippled-0.30.1"
|
||||
}
|
||||
],
|
||||
"status" : "success"
|
||||
}
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
|
||||
応答は[標準フォーマット][]に従っており、正常に完了した場合は結果に次のフィールドからなるJSONオブジェクトが含まれます。
|
||||
|
||||
| `Field` | 型 | 説明 |
|
||||
|:----------|:-------|:--------------------------------------------------------|
|
||||
| `cluster` | オブジェクト | [クラスターとして構成されている](clustering.html)場合は、同じクラスター内の他の`rippled`サーバーの概要。[新規: rippled 0.30.1][] |
|
||||
| `peers` | 配列 | peerオブジェクトからなる配列。 |
|
||||
|
||||
`cluster`オブジェクトの各フィールドは、該当する`rippled`サーバーの識別用キーペアの公開鍵です。（これは、[server_infoメソッド][]で当該サーバーから`pubkey_node`として返される値と同じです。）そのフィールドの内容は、以下のフィールドを持つオブジェクトです。
|
||||
|
||||
| `Field` | 型 | 説明 |
|
||||
|:--------|:-------|:----------------------------------------------------------|
|
||||
| `tag` | 文字列 | 構成ファイルで定義されているこのクラスターメンバーの表示名。 |
|
||||
| `fee` | 数値 | （省略される場合があります）このクラスターメンバーが[トランザクションコスト](transaction-cost.html)に適用する負荷乗数。 |
|
||||
| `age` | 数値 | このクラスターメンバーからの最終クラスターレポート以降の経過秒数。 |
|
||||
|
||||
`peers`配列の各メンバーは、以下のフィールドを持つpeerオブジェクトです。
|
||||
|
||||
| `Field` | 型 | 説明 |
|
||||
|:-------------------|:--------|:----------------------------------------------|
|
||||
| `address` | 文字列 | このピアが接続しているIPアドレスとポート。 |
|
||||
| `cluster` | ブール値 | （省略される場合があります）`true`の場合、現在のサーバーとピアサーバーは同じ`rippled`クラスターに含まれています。 |
|
||||
| `name` | 文字列 | （省略される場合があります）ピアが同じクラスターに含まれている場合、この名前は構成ファイルで定義されているそのピアサーバーの表示名です。 |
|
||||
| `complete_ledgers` | 文字列 | ピア`rippled`で利用可能なレジャーバージョンのシーケンス番号を示す範囲式 |
|
||||
| `inbound` | ブール値 | （省略される場合があります）`true`の場合は、ピアはローカルサーバーに接続しています。 |
|
||||
| `latency` | 数値 | ピアへのネットワーク遅延（ミリ秒単位） |
|
||||
| `ledger` | 文字列 | 最後に閉鎖されたピアのレジャーのハッシュ。 |
|
||||
| `load` | 数値 | ピアサーバーによるローカルサーバーへの負荷の測定値。この数値が大きいほど負荷が高くなります。（負荷の測定単位は正式には定義されていません。） |
|
||||
| `protocol` | 文字列 | （省略される場合があります）ピアが使用しているプロトコルバージョン（ローカルサーバーのプロトコルバージョンと異なる場合）。 |
|
||||
| `public_key` | 文字列 | （省略される場合があります）ピアのメッセージの整合性の検証に使用できる公開鍵。これは、検証に使用する公開鍵とは異なりますが、フォーマットは同じです。 |
|
||||
| `sanity` | 文字列 | （省略される場合があります）このピアが現行サーバーと同じルールとレジャーシーケンスに従っているかどうか。値が`insane`の場合、ピアは並列ネットワークの一部である可能性があります。値が`unknown`の場合、現行サーバーはピアに互換性があるかどうかを把握していません。 <!-- STYLE_OVERRIDE: insane --> |
|
||||
| `status` | 文字列 | （省略される場合があります）ピアからの最新のステータスメッセージ。`connecting`、`connected`、`monitoring`、`validating`、`shutting`のいずれかです。 |
|
||||
| `uptime` | 数値 | `rippled`サーバーがこのピアに継続して接続していた秒数。[新規: rippled 0.30.1][] |
|
||||
| `version` | 文字列 | （省略される場合があります）ピアサーバーの`rippled`バージョン番号 |
|
||||
|
||||
### 考えられるエラー
|
||||
|
||||
* [汎用エラータイプ][]のすべて。
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -0,0 +1,236 @@
|
||||
# print
|
||||
[[ソース]<br>](https://github.com/ripple/rippled/blob/315a8b6b602798a4cff4d8e1911936011e12abdb/src/ripple/rpc/handlers/Print.cpp "Source")
|
||||
|
||||
`print`コマンドは、さまざまな内部サブシステム（ピア、レジャークリーナー、リソースマネージャーなど）の現在の状況を返します。
|
||||
|
||||
*`print`要求は、権限のないユーザーは実行できない[管理メソッド](admin-rippled-methods.html)です。*
|
||||
|
||||
### 要求フォーマット
|
||||
要求フォーマットの例:
|
||||
|
||||
<!-- MULTICODE_BLOCK_START -->
|
||||
|
||||
*WebSocket*
|
||||
|
||||
```
|
||||
{
|
||||
"id": "print_req_1",
|
||||
"command": "print"
|
||||
}
|
||||
```
|
||||
|
||||
*コマンドライン*
|
||||
|
||||
```
|
||||
rippled print
|
||||
```
|
||||
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
|
||||
要求にはパラメーターが含まれていません。
|
||||
|
||||
### 応答フォーマット
|
||||
|
||||
処理が成功した応答の例:
|
||||
|
||||
<!-- MULTICODE_BLOCK_START -->
|
||||
|
||||
*コマンドライン*
|
||||
|
||||
```
|
||||
Loading: "/etc/rippled.cfg"
|
||||
Connecting to 127.0.0.1:5005
|
||||
{
|
||||
"result" : {
|
||||
"app" : {
|
||||
"ledgercleaner" : {
|
||||
"status" : "idle"
|
||||
},
|
||||
"peers" : {
|
||||
"peerfinder" : {
|
||||
"bootcache" : {
|
||||
"entries" : 109
|
||||
},
|
||||
"config" : {
|
||||
"auto_connect" : "true",
|
||||
"features" : "",
|
||||
"max_peers" : 21,
|
||||
"out_peers" : 10,
|
||||
"port" : 51235,
|
||||
"want_incoming" : "true"
|
||||
},
|
||||
"counts" : {
|
||||
"accept" : 0,
|
||||
"close" : 0,
|
||||
"cluster" : "0",
|
||||
"connect" : 0,
|
||||
"fixed" : "0",
|
||||
"in" : "0/11",
|
||||
"out" : "10/10",
|
||||
"total" : "10"
|
||||
},
|
||||
"fixed" : 0,
|
||||
"livecache" : {
|
||||
"entries" : [
|
||||
{
|
||||
"address" : "23.239.3.247:51235",
|
||||
"expires" : "30000000000 nanoseconds",
|
||||
"hops" : 2
|
||||
},
|
||||
{
|
||||
"address" : "192.170.145.88:51235",
|
||||
"expires" : "30000000000 nanoseconds",
|
||||
"hops" : 1
|
||||
},
|
||||
{
|
||||
"address" : "198.204.238.130:51235",
|
||||
"expires" : "26000024558 nanoseconds",
|
||||
"hops" : 1
|
||||
},
|
||||
{
|
||||
"address" : "203.127.12.115:51235",
|
||||
"expires" : "26000024558 nanoseconds",
|
||||
"hops" : 2
|
||||
},
|
||||
{
|
||||
"address" : "212.83.147.67:51235",
|
||||
"expires" : "26000024558 nanoseconds",
|
||||
"hops" : 2
|
||||
}
|
||||
],
|
||||
"hist" : "0, 10, 74, 10, 0, 0, 0, 0",
|
||||
"size" : "94"
|
||||
},
|
||||
"peers" : [
|
||||
{
|
||||
"local_address" : "10.1.10.78:48923",
|
||||
"remote_address" : "52.24.43.83:51235",
|
||||
"state" : "active"
|
||||
},
|
||||
{
|
||||
"local_address" : "10.1.10.78:50004",
|
||||
"remote_address" : "52.26.205.197:51235",
|
||||
"state" : "active"
|
||||
},
|
||||
{
|
||||
"local_address" : "10.1.10.78:37019",
|
||||
"remote_address" : "168.1.60.132:51235",
|
||||
"state" : "active"
|
||||
},
|
||||
{
|
||||
"local_address" : "10.1.10.78:38775",
|
||||
"remote_address" : "192.170.145.88:51235",
|
||||
"state" : "active"
|
||||
},
|
||||
{
|
||||
"local_address" : "10.1.10.78:34793",
|
||||
"remote_address" : "198.204.238.130:51235",
|
||||
"state" : "active"
|
||||
}
|
||||
]
|
||||
}
|
||||
},
|
||||
"resource" : {
|
||||
"admin" : [
|
||||
{
|
||||
"balance" : 0,
|
||||
"count" : 1,
|
||||
"name" : "\"127.0.0.1\""
|
||||
}
|
||||
],
|
||||
"inactive" : [],
|
||||
"inbound" : [],
|
||||
"outbound" : [
|
||||
{
|
||||
"balance" : 23,
|
||||
"count" : 1,
|
||||
"name" : "93.190.138.234:51235"
|
||||
},
|
||||
{
|
||||
"balance" : 35,
|
||||
"count" : 1,
|
||||
"name" : "198.204.238.130:51235"
|
||||
},
|
||||
{
|
||||
"balance" : 31,
|
||||
"count" : 1,
|
||||
"name" : "52.26.205.197:51235"
|
||||
},
|
||||
{
|
||||
"balance" : 32,
|
||||
"count" : 1,
|
||||
"name" : "54.186.73.52:51235"
|
||||
},
|
||||
{
|
||||
"balance" : 15,
|
||||
"count" : 1,
|
||||
"name" : "72.251.233.164:51235"
|
||||
}
|
||||
]
|
||||
},
|
||||
"server" : {
|
||||
"active" : "2",
|
||||
"hist" : "16",
|
||||
"history" : [
|
||||
{
|
||||
"bytes_in" : "214",
|
||||
"bytes_out" : "11688",
|
||||
"elapsed" : "0 seconds",
|
||||
"id" : "16",
|
||||
"requests" : 1,
|
||||
"when" : "2015-Jun-16 16:33:50"
|
||||
},
|
||||
{
|
||||
"bytes_in" : "214",
|
||||
"bytes_out" : "11431",
|
||||
"elapsed" : "0 seconds",
|
||||
"id" : "15",
|
||||
"requests" : 1,
|
||||
"when" : "2015-Jun-16 16:11:59"
|
||||
},
|
||||
{
|
||||
"bytes_in" : "227",
|
||||
"bytes_out" : "337",
|
||||
"elapsed" : "0 seconds",
|
||||
"id" : "3",
|
||||
"requests" : 1,
|
||||
"when" : "2015-Jun-16 14:57:23"
|
||||
},
|
||||
{
|
||||
"bytes_in" : "214",
|
||||
"bytes_out" : "2917",
|
||||
"elapsed" : "0 seconds",
|
||||
"id" : "2",
|
||||
"requests" : 1,
|
||||
"when" : "2015-Jun-16 12:39:29"
|
||||
},
|
||||
{
|
||||
"bytes_in" : "220",
|
||||
"bytes_out" : "1426",
|
||||
"elapsed" : "0 seconds",
|
||||
"id" : "1",
|
||||
"requests" : 1,
|
||||
"when" : "2015-Jun-16 12:39:13"
|
||||
}
|
||||
]
|
||||
},
|
||||
"validators" : {}
|
||||
},
|
||||
"status" : "success"
|
||||
}
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
|
||||
応答は[標準フォーマット][]に従っています。結果に含まれる追加フィールドは、`rippled`サーバーの内部状態に応じて異なります。このコマンドの実行結果は、予告なく変更されることがあります。
|
||||
|
||||
### 考えられるエラー
|
||||
|
||||
* [汎用エラータイプ][]のすべて。
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -0,0 +1,134 @@
|
||||
# validator_list_sites
|
||||
[[ソース]<br>](https://github.com/ripple/rippled/blob/master/src/ripple/rpc/handlers/ValidatorListSites.cpp "Source")
|
||||
|
||||
`validator_list_sites`コマンドは、バリデータリストを処理するサイトのステータス情報を返します。[新規: rippled 0.80.1][]
|
||||
|
||||
*`validator_list_sites`要求は、権限のないユーザーは実行できない[管理メソッド](admin-rippled-methods.html)です。*
|
||||
|
||||
### 要求フォーマット
|
||||
要求フォーマットの例:
|
||||
|
||||
<!-- MULTICODE_BLOCK_START -->
|
||||
|
||||
*WebSocket*
|
||||
|
||||
```
|
||||
{
|
||||
"id": 1,
|
||||
"command": "validator_list_sites"
|
||||
}
|
||||
```
|
||||
|
||||
*JSON-RPC*
|
||||
|
||||
```
|
||||
{
|
||||
"method": "validator_list_sites",
|
||||
"params": [
|
||||
{}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
*コマンドライン*
|
||||
|
||||
```
|
||||
#Syntax: validator_list_sites
|
||||
rippled validator_list_sites
|
||||
```
|
||||
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
|
||||
要求にはパラメーターが含まれていません。
|
||||
|
||||
### 応答フォーマット
|
||||
|
||||
処理が成功した応答の例:
|
||||
|
||||
<!-- MULTICODE_BLOCK_START -->
|
||||
|
||||
*WebSocket*
|
||||
|
||||
```
|
||||
{
|
||||
"id":5,
|
||||
"status":"success",
|
||||
"type":"response",
|
||||
"result": {
|
||||
"validator_sites": [
|
||||
{
|
||||
"last_refresh_status": "accepted",
|
||||
"last_refresh_time": "2017-Oct-13 21:26:37",
|
||||
"refresh_interval_min": 5,
|
||||
"uri": "http://127.0.0.1:51447/validators"
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
*JSON-RPC*
|
||||
|
||||
```
|
||||
200 OK
|
||||
{
|
||||
"result": {
|
||||
"status": "success",
|
||||
"validator_sites": [
|
||||
{
|
||||
"last_refresh_status": "accepted",
|
||||
"last_refresh_time": "2017-Oct-13 21:26:37",
|
||||
"refresh_interval_min": 5,
|
||||
"uri": "http://127.0.0.1:51447/validators"
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
*コマンドライン*
|
||||
|
||||
```
|
||||
Loading: "/etc/rippled.cfg"
|
||||
Connecting to 127.0.0.1:5005
|
||||
{
|
||||
"result": {
|
||||
"status": "success",
|
||||
"validator_sites": [
|
||||
{
|
||||
"last_refresh_status": "accepted",
|
||||
"last_refresh_time": "2017-Oct-13 21:26:37",
|
||||
"refresh_interval_min": 5,
|
||||
"uri": "http://127.0.0.1:51447/validators"
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
|
||||
応答は[標準フォーマット][]に従っており、正常に完了した場合は結果に次のフィールドが含まれています。
|
||||
|
||||
| `Field` | 型 | 説明 |
|
||||
|:------------------|:------|----------------------------------|
|
||||
| `validator_sites` | 配列 | バリデータサイトオブジェクトからなる配列。 |
|
||||
|
||||
`validator_sites`フィールドの配列の各メンバーは、次のフィールドを有するオブジェクトです。
|
||||
|
||||
| `Field` | 型 | 説明 |
|
||||
|:-----------------------|:-----------------|:--------------------------------|
|
||||
| `last_refresh_status` | 文字列 | 存在する場合は、サイトの最終更新の[`ListDisposition`](https://github.com/ripple/rippled/blob/master/src/ripple/app/misc/ValidatorList.h)です。存在しない場合は、サイトに対するクエリーがまだ成功していません。 |
|
||||
| `last_refresh_time` | 文字列 | サイトの最終照会時刻を人間が読み取れる形式で表示します。存在しない場合は、サイトに対するクエリーがまだ成功していません。 |
|
||||
| `refresh_interval_min` | 符号なし整数 | 更新試行間隔の分数。 |
|
||||
| `uri` | 文字列 | サイトのURI。 |
|
||||
|
||||
### 考えられるエラー
|
||||
|
||||
* [汎用エラータイプ][]のすべて。
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -0,0 +1,182 @@
|
||||
# validators
|
||||
[[ソース]<br>](https://github.com/ripple/rippled/blob/master/src/ripple/rpc/handlers/Validators.cpp "Source")
|
||||
|
||||
`validators`コマンドは、サーバーが使用する公開済みの信頼できるバリデータの最新リストに関する情報を、人間が読み取れる形式で返します。[新規: rippled 0.80.1][]
|
||||
|
||||
*`validators`要求は、権限のないユーザーは実行できない[管理メソッド](admin-rippled-methods.html)です。*
|
||||
|
||||
### 要求フォーマット
|
||||
要求フォーマットの例:
|
||||
|
||||
<!-- MULTICODE_BLOCK_START -->
|
||||
|
||||
*WebSocket*
|
||||
|
||||
```
|
||||
{
|
||||
"id": 1,
|
||||
"command": "validators"
|
||||
}
|
||||
```
|
||||
|
||||
*JSON-RPC*
|
||||
|
||||
```
|
||||
{
|
||||
"method": "validators",
|
||||
"params": [
|
||||
{}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
*コマンドライン*
|
||||
|
||||
```
|
||||
#Syntax: validators
|
||||
rippled validators
|
||||
```
|
||||
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
|
||||
要求にはパラメーターが含まれていません。
|
||||
|
||||
### 応答フォーマット
|
||||
|
||||
処理が成功した応答の例:
|
||||
|
||||
<!-- MULTICODE_BLOCK_START -->
|
||||
|
||||
*WebSocket*
|
||||
|
||||
```
|
||||
{
|
||||
"id":5,
|
||||
"status":"success",
|
||||
"type":"response",
|
||||
"result":{
|
||||
"local_static_keys": [],
|
||||
"publisher_lists":[
|
||||
{
|
||||
"available":true,
|
||||
"expiration":"2017-Oct-13 14:56:00",
|
||||
"list":[
|
||||
"n9Ltz6ZxPRWTkqwBbpvgbaXPgm6GYCxCJRqFgNXhWVUebgezo28H",
|
||||
"n94D73ZKSUaTDCnUqYW5ugJ9fHPNxda9GQVoWA6BGtcKuuhozrD1"
|
||||
],
|
||||
"pubkey_publisher":"ED58ED4AA543B524F16771F6E1367BAA220D99DCF22CD8CF7A11309E9EAB1B647B",
|
||||
"seq":1,
|
||||
"version":1
|
||||
}
|
||||
],
|
||||
"signing_keys":{},
|
||||
"status":"success",
|
||||
"trusted_validator_keys":[
|
||||
"n94D73ZKSUaTDCnUqYW5ugJ9fHPNxda9GQVoWA6BGtcKuuhozrD1",
|
||||
"n9Ltz6ZxPRWTkqwBbpvgbaXPgm6GYCxCJRqFgNXhWVUebgezo28H"
|
||||
],
|
||||
"validation_quorum":2,
|
||||
"validator_list_expires":"2017-Oct-13 14:56:00"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
*JSON-RPC*
|
||||
|
||||
```
|
||||
200 OK
|
||||
{
|
||||
"result":{
|
||||
"local_static_keys": [],
|
||||
"publisher_lists":[
|
||||
{
|
||||
"available":true,
|
||||
"expiration":"2017-Oct-13 14:56:00",
|
||||
"list":[
|
||||
"n9Ltz6ZxPRWTkqwBbpvgbaXPgm6GYCxCJRqFgNXhWVUebgezo28H",
|
||||
"n94D73ZKSUaTDCnUqYW5ugJ9fHPNxda9GQVoWA6BGtcKuuhozrD1"
|
||||
],
|
||||
"pubkey_publisher":"ED58ED4AA543B524F16771F6E1367BAA220D99DCF22CD8CF7A11309E9EAB1B647B",
|
||||
"seq":1,
|
||||
"version":1
|
||||
}
|
||||
],
|
||||
"signing_keys":{},
|
||||
"status":"success",
|
||||
"trusted_validator_keys":[
|
||||
"n94D73ZKSUaTDCnUqYW5ugJ9fHPNxda9GQVoWA6BGtcKuuhozrD1",
|
||||
"n9Ltz6ZxPRWTkqwBbpvgbaXPgm6GYCxCJRqFgNXhWVUebgezo28H"
|
||||
],
|
||||
"validation_quorum":2,
|
||||
"validator_list_expires":"2017-Oct-13 14:56:00"
|
||||
},
|
||||
"status":"success"
|
||||
}
|
||||
```
|
||||
|
||||
*コマンドライン*
|
||||
|
||||
```
|
||||
Loading: "/etc/rippled.cfg"
|
||||
Connecting to 127.0.0.1:5005
|
||||
{
|
||||
"result":{
|
||||
"local_static_keys": [],
|
||||
"publisher_lists":[
|
||||
{
|
||||
"available":true,
|
||||
"expiration":"2017-Oct-13 14:56:00",
|
||||
"list":[
|
||||
"n9Ltz6ZxPRWTkqwBbpvgbaXPgm6GYCxCJRqFgNXhWVUebgezo28H",
|
||||
"n94D73ZKSUaTDCnUqYW5ugJ9fHPNxda9GQVoWA6BGtcKuuhozrD1"
|
||||
],
|
||||
"pubkey_publisher":"ED58ED4AA543B524F16771F6E1367BAA220D99DCF22CD8CF7A11309E9EAB1B647B",
|
||||
"seq":1,
|
||||
"version":1
|
||||
}
|
||||
],
|
||||
"signing_keys":{},
|
||||
"status":"success",
|
||||
"trusted_validator_keys":[
|
||||
"n94D73ZKSUaTDCnUqYW5ugJ9fHPNxda9GQVoWA6BGtcKuuhozrD1",
|
||||
"n9Ltz6ZxPRWTkqwBbpvgbaXPgm6GYCxCJRqFgNXhWVUebgezo28H"
|
||||
],
|
||||
"validation_quorum":2,
|
||||
"validator_list_expires":"2017-Oct-13 14:56:00"
|
||||
},
|
||||
"status":"success"
|
||||
}
|
||||
```
|
||||
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
|
||||
応答は[標準フォーマット][]に従っており、正常に完了した場合は結果に次のフィールドが含まれています。
|
||||
|
||||
| `Field` | 型 | 説明 |
|
||||
|:-------------------------|:-------|:-----------------------------------------|
|
||||
| `listed_static_keys` | 配列 | 信頼リストに常に追加可能なバリデータの公開鍵の配列。 |
|
||||
| `publisher_lists` | 配列 | パブリッシャーリストオブジェクトの配列。 |
|
||||
| `signing_keys` | オブジェクト | バリデータマニフェストを使用している登録済みバリデータのマスター公開鍵から、現在の署名キーへのマッピング。 |
|
||||
| `trusted_validator_keys` | 配列 | 現在信頼されているバリデータの公開鍵の配列。 |
|
||||
| `validation_quorum` | 数値 | 1つのレジャーバージョンの検証に最低限必要となる信頼できる検証の数。状況によっては、サーバーがさらに検証を要求する場合があります。 |
|
||||
| `validator_list_expires` | 文字列 | 人間が読み取れる形式での現在のバリデータリストの有効期限、文字列`unknown`（サーバーが公開済みバリデータリストを読み込む必要がある場合）、または文字列`never`（サーバーが静的なバリデータリストを使用している場合）のいずれか。 |
|
||||
|
||||
`publisher_lists`配列の各メンバーは、以下のフィールドを有するオブジェクトです。
|
||||
|
||||
| `Field` | 型 | 説明 |
|
||||
|:-------------------|:-----------------|:-------------------------------------|
|
||||
| `available` | ブール値 | `false`の場合、`list`内のバリデータキーはこのパブリッシャーによりサポートされていない可能性があります。 |
|
||||
| `expiration` | 文字列 | この公開済みリストの有効期限を人間が読み取れる形式で示します。 |
|
||||
| `list` | 配列 | 公開済みバリデータキーからなる配列。 |
|
||||
| `pubkey_publisher` | 文字列 | リストパブリッシャーのEd25519またはECDSA公開鍵（16進数）。 |
|
||||
| `seq` | 符号なし整数 | 公開済みリストのシーケンス番号。 |
|
||||
| `version` | 符号なし整数 | リストフォーマットのバージョン。 |
|
||||
|
||||
### 考えられるエラー
|
||||
|
||||
* [汎用エラータイプ][]のすべて。
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -0,0 +1,5 @@
|
||||
# APIの規則
|
||||
|
||||
このセクションでは、JSON-RPCおよびWebSocketインターフェイスを含む`rippled` APIのデータ型とフォーマットについて説明します。
|
||||
|
||||
これらのデータ型の一部は、[Data API](data-api.html)を含む、より高度なAPIにも使用されます。
|
||||
@@ -0,0 +1,31 @@
|
||||
# base58エンコード
|
||||
|
||||
`rippled` APIでは、チェックサムを含む[base58](https://en.wikipedia.org/wiki/Base58)エンコード（「Base58Check」とも呼ばれます）を使用して[アカウントアドレス](accounts.html#アドレス)や暗号鍵に関連するその他のタイプの値が表現されることがよくあります。このエンコードは、Bitcoinのアドレスに使用されているエンコードと同じですが、XRP Ledgerでは以下のディクショナリが使用される点が異なります。`rpshnaf39wBUDNEGHJKLM4PQRST7VWXYZ2bcdeCg65jkm8oFqi1tuvAxyz`。
|
||||
|
||||
XRP Ledgerにより、さまざまなタイプの値をエンコードする前に、データタイプを区別する固有の8ビット数値が値の前に付加されます。XRP Ledgerのbase58ディクショナリの文字配列と組み合わされた、さまざまなタイプのエンコード値のbase58表現は、タイプごとに固有の文字で始まります。
|
||||
|
||||
以下の表に、XRP Ledgerで使用されるすべてのエンコードを示します。
|
||||
|
||||
| データタイプ | 開始文字 | タイププレフィクス | コンテンツのサイズ¹ | 最大文字数 |
|
||||
|:-----------------------------|:------------|:---------------|:--------------|:--|
|
||||
| [アカウント][]アドレス | r | `0x00` | 20バイト | 35 |
|
||||
| アカウントの公開鍵 | a | `0x23` | 33バイト | 53 |
|
||||
| シード値（シークレットキー） | s | `0x21` | 16バイト | 29 |
|
||||
| 検証の公開鍵 | n | `0x1C` | 33バイト | 53 |
|
||||
|
||||
¹ コンテンツのサイズでは1バイトのタイププレフィクスは除外されます。
|
||||
|
||||
[アカウント]: accounts.html
|
||||
|
||||
## 関連項目
|
||||
|
||||
- [アドレスのエンコード](accounts.html#アドレスのエンコード) - アドレスのエンコードについての詳細な情報
|
||||
- [暗号鍵](cryptographic-keys.html) - XRP Ledgerの暗号鍵のタイプとその使用法
|
||||
- [wallet_proposeリファレンス][wallet_propose method] - アカウントキーを生成するためのAPIメソッド
|
||||
- [validation_createリファレンス][validation_create method] - バリデータキーを生成するためのAPIメソッド
|
||||
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -0,0 +1,165 @@
|
||||
# 基本的なデータ型
|
||||
|
||||
さまざまなタイプのオブジェクトがそれぞれ異なる方法で一意に識別されます。
|
||||
|
||||
[アカウント](accounts.html)は[アドレス][]で識別されます。例えば、`"r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59"`など。アドレスは常に「r」で始まります。`rippled`メソッドの多くは、16進数表記に対応しています。
|
||||
|
||||
[トランザクション](transaction-formats.html)は、トランザクションのバイナリフォーマットの[ハッシュ][]で識別されます。また、トランザクションは送信アカウントと[シーケンス番号][]でも識別できます。
|
||||
|
||||
閉鎖された各[レジャー](ledger-data-formats.html)は、[レジャーインデックス][]と[ハッシュ][]値を保有します。[レジャーを指定する](#レジャーの指定)場合、いずれか1つを使用できます。
|
||||
|
||||
## アドレス
|
||||
[アドレス]: #アドレス
|
||||
|
||||
{% include '_snippets/data_types/address.md' %}
|
||||
<!--{#_ #}-->
|
||||
|
||||
|
||||
## ハッシュ
|
||||
[ハッシュ]: #ハッシュ
|
||||
|
||||
{% include '_snippets/data_types/hash.md' %}
|
||||
<!--{#_ #}-->
|
||||
|
||||
### ハッシュプレフィクス
|
||||
[[ソース]<br>](https://github.com/ripple/rippled/blob/master/src/ripple/protocol/HashPrefix.h "Source")
|
||||
|
||||
多くの場合、XRP Ledgerではオブジェクトのバイナリデータに4バイトのプレフィクスを付けてからハッシュを計算するため、異なるタイプのオブジェクトが同じバイナリフォーマットである場合でも、異なるハッシュが設定されます。既存の4バイトコードは、ASCIIでエンコードされた英字3文字の後に0バイトが続く構成となっています。
|
||||
|
||||
ある種のハッシュは、APIの要求と応答に使用されます。またある種のデータに署名するときの最初のステップで計算されるだけのものや、より高度なハッシュを計算するためのものもあります。XRP Ledgerで使用されるすべての4バイトのハッシュプレフィクスは以下の表の通りです。
|
||||
|
||||
| オブジェクトタイプ | APIフィールド | ハッシュプレフィクス（16進数） | ハッシュプレフィクス（テキスト） |
|
||||
|:--------------------------------------|:-------------------------------------|:------------------|:--|
|
||||
| コンセンサスの提案 | なし | `0x50525000` | `PRP\0` |
|
||||
| レジャーバージョン | `ledger_hash` | `0x4C575200` | `LWR\0` |
|
||||
| レジャー状態データ | `account_state` （[レジャーヘッダー][]内） | `0x4D4C4E00` | `MLN\0` |
|
||||
| レジャーデータ内部ノード | なし | `0x4D494E00` | `MIN\0` |
|
||||
| レジャーデータ内部ノード（[SHAMapv2][]） | なし | `0x494E5200` | `INR\0` |
|
||||
| Payment Channelのクレーム | なし | `0x434C4D00` | `CLM\0` |
|
||||
| 署名済みのトランザクション | トランザクションの`hash` | `0x54584E00` | `TXN\0` |
|
||||
| メタデータを持つトランザクション | なし | `0x534E4400` | `SND\0` |
|
||||
| 未署名のトランザクション（シングル署名） | なし | `0x53545800` | `STX\0` |
|
||||
| 未署名のトランザクション（マルチ署名） | なし | `0x534D5400` | `SMT\0` |
|
||||
| 検証の投票 | なし | `0x56414C00` | `VAL\0` |
|
||||
| バリデータサブキー認証（「バリデータマニフェスト」） | なし | `0x4D414E00` | `MAN\0` |
|
||||
|
||||
[レジャーヘッダー]: ledger-header.html
|
||||
[SHAMapv2]: known-amendments.html#shamapv2
|
||||
|
||||
[レジャーオブジェクトID](ledger-object-ids.html)も似た方法で計算されますが、ここで説明したプレフィクスの代わりに「スペースキー」という2バイトのプレフィクスを使用します。
|
||||
|
||||
|
||||
## アカウントシーケンス
|
||||
[シーケンス番号]: #アカウントシーケンス
|
||||
|
||||
{% include '_snippets/data_types/account_sequence.md' %}
|
||||
<!--{#_ #}-->
|
||||
|
||||
|
||||
## レジャーインデックス
|
||||
[レジャーインデックス]: #レジャーインデックス
|
||||
|
||||
{% include '_snippets/data_types/ledger_index.md' %}
|
||||
<!--{#_ #}-->
|
||||
|
||||
|
||||
### レジャーの指定
|
||||
|
||||
APIメソッドの多くは、レジャーのインスタンスを指定する必要があります。その場合、共有されたレジャーの特定バージョンで最新と見なされるデータで指定する必要があります。レジャーバージョンを受け入れるコマンドは、すべて同様に機能します。使用するレジャーを指定するには、以下の3つの方法があります。
|
||||
|
||||
1. `ledger_index`パラメーターにレジャーの[レジャーインデックス][]を指定します。閉鎖された各レジャーには識別用のシーケンス番号が付いていて、その前に検証されたレジャーより1つ大きい番号になります。（ジェネシスレジャーのシーケンス番号は0です。）
|
||||
2. `ledger_hash`パラメーターにレジャーの[ハッシュ][]値を指定します。
|
||||
3. `ledger_index`パラメーターに以下のいずれかのショートカットを指定します。
|
||||
* `validated`: ネットワーク全体で検証された最新のレジャー
|
||||
* `closed`: 変更できないように閉鎖され、検証を提案されている最新のレジャー
|
||||
* `current`: サーバーで現在処理中のレジャーバージョン
|
||||
|
||||
上記3つのフォーマットすべてを受け入れる、廃止予定の`ledger`パラメーターもあります。このパラメーターは使用*しないでください*。今後予告なしに廃止される可能性があります。
|
||||
|
||||
レジャーを指定しない場合、デフォルトで`current`（処理中）レジャーが選択されます。レジャーを指定するフィールドを複数指定した場合、廃止予定の`ledger`フィールドが最初に使用され（存在する場合）、`ledger_hash`に戻ります。`ledger_index`フィールドは、他の2つのフィールドがいずれも存在しない場合を除いて無視されます。
|
||||
|
||||
**注記:** レジャーを指定する際に上記のデフォルトの動作に頼らないでください。変更される場合があります。可能であれば、常に要求にてレジャーバージョンを指定してください。
|
||||
|
||||
|
||||
## 通貨
|
||||
|
||||
XRP Ledgerには2種類の通貨があります。XRPとその他のあらゆる通貨です。この2つには多くの相違点があります。
|
||||
|
||||
| `XRP` | 発行済み通貨 |
|
||||
|:----------------------------------------------------------------|:-----------|
|
||||
| 発行者なし | 必ずXRP Ledgerアカウントが発行 |
|
||||
| 文字列として指定 | オブジェクトとして指定 |
|
||||
| [アカウント](accountroot.html)内で追跡 | [トラストライン](ripplestate.html)内で追跡 |
|
||||
| 作成は一切不可、消却のみ可能 | 自由に発行または清算可能 |
|
||||
| 最大値: `100000000000`（`1e11`） | 最大値: `9999999999999999e80` |
|
||||
| [「drop」](#xrp)（0.000001 XRP）に近い精度 | 10進15桁の精度で非ゼロの最少絶対値は `1000000000000000e-96` |
|
||||
|
||||
**注意:** XRP Ledgerでは、通常の浮動小数点数とは異なる精度の小数点計算を使用するため、通貨額は常に文字列として表されます。
|
||||
|
||||
### 通貨額の指定
|
||||
|
||||
一部のAPIメソッドでは、通貨額を指定する必要があります。取扱通貨がネットワーク固有のXRP通貨であるかその他の通貨単位（_イシュアンス_）であるかによって、指定方法が大きく異なります。
|
||||
|
||||
#### XRP
|
||||
[XRPのdrop数]: #xrp
|
||||
[XRP、drop単位]: #xrp
|
||||
|
||||
XRPの額は文字列で表します。（XRPの精度は64ビット整数と同等ですが、JSON 整数は32ビットに制限されるため、JSON整数で表す場合はXRPがオーバーフローする恐れがあります。）XRPは正式には「drop」で指定します。これは0.000001（百万分の1）のXRPと等価です。したがって、JSON文書で1.0 XRPを表示するには、次のように書きます。
|
||||
|
||||
```
|
||||
"1000000"
|
||||
```
|
||||
|
||||
**XRPをオブジェクトに指定しないでください。**
|
||||
|
||||
単体テストでは、XRPの値（dropではありません）を小数点を使用して指定できます。例えば、「1.23」は1.23 XRPを意味します。それ以外のすべての場合では、XRPは常にdrop単位で指定し、小数点は使用しません。例えば、「1230000」は1.23 XRPを意味します。
|
||||
|
||||
#### 非XRP
|
||||
|
||||
XRP以外の通貨（法定通貨としてのドル、貴金属、暗号資産、その他のカスタム通貨を含む）を指定する場合、通貨指定オブジェクトを使用して指定する必要があります。以下は、3つのフィールドを持つJSONオブジェクトです。
|
||||
|
||||
| `Field` | 型 | 説明 |
|
||||
|:-----------|:---------------------------|:-----------------------------------|
|
||||
| `currency` | 文字列 - [通貨コード][] | 通貨を発行するための任意コード。`XRP`は使用できません。 |
|
||||
| `value` | 文字列 | 通貨の金額を表す引用符付き10進数表記。これには科学的記数法が含まれ、例えば`1.23e11`は123,000,000,000を意味します。`e`と`E`のどちらも使用できます。 |
|
||||
| `issuer` | 文字列 | 通貨を発行する組織の一意のアカウントアドレス。つまり、通貨を清算できる個人または企業です。 |
|
||||
|
||||
**注意:** これらのフィールド名は大文字小文字の区別があります。
|
||||
|
||||
例えば、アカウント`r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59`によって発行された$153.75 USドルは、以下のように指定します。
|
||||
|
||||
```
|
||||
{
|
||||
"currency": "USD",
|
||||
"value": "153.75",
|
||||
"issuer": "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59"
|
||||
}
|
||||
```
|
||||
|
||||
単体テストでは、非XRP通貨の金額値をスラッシュで区切られた文字列で指定できます。例えば、`"amount/currency/issuer"`のフォーマットになります。その他すべての場合では、前述のJSONオブジェクトのフォーマットを使用する必要があります。
|
||||
|
||||
#### 金額なしでの通貨の指定
|
||||
|
||||
XRP以外の通貨を金額なしで指定する場合は（主に、通貨取引オファーのオーダーブックを定義する場合など）、上記のように指定しますが、`value`フィールドは省略します。
|
||||
|
||||
XRPを金額なしで指定する場合は（主に、オーダーブックを定義する場合など）、JSONオブジェクトとして指定しますが、使用するフィールドは`currency`フィールド _のみ_ です。XRPの場合は`issuer`フィールドを指定してはいけません。
|
||||
|
||||
最後に、支払いの受取人アカウントが複数のイシュアー（通貨発行者）を信頼している場合は、受取人が受け入れているイシュアーがどのように組み合わされても支払いが行われるように指定できます。これを行うには、受取人アカウントのアドレスをJSONオブジェクトに`issuer`値として指定します。
|
||||
|
||||
### 通貨コード
|
||||
[通貨コード]: #通貨コードs
|
||||
|
||||
{% include '_snippets/data_types/currency_code.md' %}
|
||||
<!--{#_ #}-->
|
||||
|
||||
|
||||
## 時間の指定
|
||||
|
||||
`rippled`サーバーとそのAPIでは、時間を符号なし整数で表します。この数値は、「Rippleエポック」である2000年1月1日（00:00 UTC）から経過した秒数を表しています。これは[UNIXエポック](http://en.wikipedia.org/wiki/Unix_time)と同様に機能しますが、RippleエポックはUNIXエポックより946684800秒遅れています。
|
||||
|
||||
Rippleエポック時間を32ビット変数でUNIXエポック時間に変換しないでください。整数のオーバーフローが発生する恐れがあります。
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -0,0 +1,66 @@
|
||||
# 通貨フォーマット
|
||||
|
||||
XRP Ledgerには2種類の通貨（[XRP](xrp.html)と[発行済み通貨](issued-currencies.html)）があります。XRP Ledgerでは、これらの通貨のフォーマットは異なりますが、いずれの通貨も高精度です。
|
||||
|
||||
## 文字列フォーマット
|
||||
|
||||
{% include '_snippets/string-number-formatting.md' %}
|
||||
<!--{#_ #}-->
|
||||
|
||||
## XRPの精度
|
||||
|
||||
XRPの精度は、64ビット符号なし整数と同等であり、各単位は0.000001 XRPと同等です。プロパティは次の通りです。
|
||||
|
||||
* 最小値: `0`
|
||||
* 最大値: `100000000000`（10<sup>11</sup>）XRP
|
||||
- `"100000000000000000"`（10<sup>17</sup>） dropのXRP
|
||||
* `0.000001`（10<sup>-6</sup>）XRPに近い精度
|
||||
- `"1"` dropのXRP
|
||||
|
||||
## 発行済み通貨の精度
|
||||
|
||||
XRP Ledgerの発行済み通貨は、以下の精度のカスタムフォーマットで表現されます。
|
||||
|
||||
* 非ゼロの最小絶対値: `1000000000000000e-96`
|
||||
* 最大値: `9999999999999999e80`
|
||||
* 最小値: `-9999999999999999e80`
|
||||
* 10進15桁の精度
|
||||
|
||||
## 発行済み通貨の計算
|
||||
[[ソース]<br>](https://github.com/ripple/rippled/blob/35fa20a110e3d43ffc1e9e664fc9017b6f2747ae/src/ripple/protocol/impl/STAmount.cpp "Source")
|
||||
|
||||
|
||||
|
||||
`rippled`内部では発行済み通貨の数値はカスタムの数値フォーマットで表現されます。このフォーマットではさまざまな資産（一般的にごく小さな単位または極めて大きな単位で測定される資産を含む）を保管できます。このフォーマットでは、有効数字と10のべき乗の指数を科学的記数法と同様の方法で使用します。このフォーマットは、指定された範囲内のプラスまたはマイナスの有効桁数と指数に対応しています。非整数値の一般的な浮動小数点表記とは異なり、このフォーマットでは整数を用いて計算します。このため、常に15桁の精度が維持されます。乗算と除算には、最下位の有効数字の丸め過ぎを補う調整機能があります。
|
||||
|
||||
「任意精度」の数値フォーマットとは異なり、カスタムフォーマットは64ビットの固定サイズで格納できます。このようにシリアル化される場合、このフォーマットは「非XRP」ビット、符号ビット、有効桁数、指数で構成されます。これらは次の順で表示されます。
|
||||
|
||||
1. 発行済み通貨額の1番目のビット（最上位ビット）は、XRPの額ではないことを示す`1`です。（XRPの額である場合、最上位ビットは常に`0`に設定され、このフォーマットからXRPの額が区別されます。）
|
||||
2. 符号ビットは、金額のプラスマイナスを示します。標準的な[2の補数で表される](https://en.wikipedia.org/wiki/Two%27s_complement)整数とは異なり、`1` はXRP Ledgerフォーマットでは**プラス**を示し`0`はマイナスを示します。
|
||||
3. 次の8ビットは、指数を符号なし整数で表しています。指数は、小数点以下桁数（有効桁数に乗算する10のべき乗）を-96以上+80以下の範囲で示します。ただしシリアル化では、この指数に97を加算して符号なし整数としてシリアル化できるようにします。したがってシリアル化された値が`1`の場合は指数`-96`、シリアル化された値が`177`の場合は指数80を示します。
|
||||
4. 残りの54ビットは、有効数字を符号なし整数で表します。シリアル化では、値0の特殊なケースを除き、この値は10<sup>15</sup>（`1000000000000000`）以上10<sup>16</sup>-1（`9999999999999999`）以下の範囲で正規化されます。値0の特殊なケースがあります。この場合符号ビット、指数、および仮数はすべてゼロであるため、64ビット値は`0x8000000000000000000000000000000000000000`としてシリアル化されます。
|
||||
|
||||
|
||||
## 通貨コード
|
||||
|
||||
XRP LedgerのXRP以外の通貨には160ビットの通貨コードがあります。[`rippled`API](rippled-api.html)では、標準マッピングを使用して3文字のASCII文字列（大文字と小文字の区別あり）が160ビットの通貨コードにマッピングされます。通貨コード`XRP`は発行済み通貨には使用できません。同一コードの通貨は接続トラストラインを通じて[ripple](rippling.html)できます。通貨コードには、XRP Ledgerに組み込まれるその他の動作はありません。
|
||||
|
||||
### 標準通貨コード
|
||||
|
||||
標準通貨マッピングによりビットが次のように割り当てられます。
|
||||
|
||||
|
||||
|
||||
1. 最初の8ビットは`0x00`でなければなりません。
|
||||
2. 次の88ビットは予約済みであり、すべて`0`です。
|
||||
3. 次の24ビットは3つのASCII文字を表します。
|
||||
[ISO 4217](http://www.xe.com/iso4217.php)コードまたはよく利用されている疑似ISO 4217コード（BTCなど）の使用が推奨されます。ただし、すべての大文字と小文字、桁数、および記号`?`、`!`、`@`、`#`、`$`、`%`、`^`、`&`、`*`、`<`、`>`、`(`、`)`、`{`、`}`、`[`、`]`、および<code>|</code>の組み合わせを使用できます。通貨コード`XRP`（すべて大文字）はXRP用に予約されており、発行済み通貨には使用できません。
|
||||
4. 次の40ビットは予約済みであり、すべて`0`です。
|
||||
|
||||
通常、XRP額の指定時には通貨コードは使用しません。フィールドにXRPの通貨コードが指定されている稀なケースでは、通貨コードのバイナリ形式はすべてゼロになります。
|
||||
|
||||
### 非標準通貨コード
|
||||
|
||||
通貨コードとして160ビット（40文字）16進文字列（例: `015841551A748AD2C1F76FF6ECB0CCCD00000000`）を使用して、その他のタイプの通貨を発行することもできます。異なる通貨コードタイプとして扱われないようにするには、先頭8ビットが`0x00`であってはなりません。
|
||||
|
||||
**廃止予定:** 一部の旧バージョンの[ripple-lib](https://github.com/ripple/ripple-lib)では通貨コードタイプとして「有利子」または「マイナス利子」がサポートされていました。これらの通貨の先頭8ビットは`0x01`です。マイナス利子/有利子通貨はサポートされなくなりましたが、レジャーデータにこのような通貨が現れることがあります。詳しくは、[マイナス利子](demurrage.html)を参照してください。
|
||||
@@ -0,0 +1,111 @@
|
||||
# エラーのフォーマット
|
||||
|
||||
エラーが発生する可能性のある状況をすべて挙げることは不可能です。トランスポートレイヤーで発生する場合（ネットワーク接続が失われる場合など）には、使用しているクライアントとトランスポートに応じてその結果は異なります。ただし、`rippled`サーバーが要求を正常に受信した場合、サーバーは標準のエラー形式での応答を試みます。
|
||||
|
||||
**注意:** 要求の結果がエラーになった場合、応答の一部として要求全体がコピーされます。このため、エラーのデバッグに取り組むことができます。ただし、これには要求で渡した機密情報がすべて含まれます。エラーメッセージを共有するときには、アカウントの重要な機密情報を他のユーザーに誤って公開することがないように、十分に注意してください。
|
||||
|
||||
|
||||
エラーの例:
|
||||
|
||||
<!-- MULTICODE_BLOCK_START -->
|
||||
|
||||
*WebSocket*
|
||||
|
||||
```
|
||||
{
|
||||
"id": 3,
|
||||
"status": "error",
|
||||
"type": "response",
|
||||
"error": "ledgerIndexMalformed",
|
||||
"request": {
|
||||
"account": "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59",
|
||||
"command": "account_info",
|
||||
"id": 3,
|
||||
"ledger_index": "-",
|
||||
"strict": true
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
*JSON-RPC*
|
||||
|
||||
```
|
||||
HTTP Status: 200 OK
|
||||
{
|
||||
"result": {
|
||||
"error": "ledgerIndexMalformed",
|
||||
"request": {
|
||||
"account": "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59",
|
||||
"command": "account_info",
|
||||
"ledger_index": "-",
|
||||
"strict": true
|
||||
},
|
||||
"status": "error"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
*コマンドライン*
|
||||
|
||||
```
|
||||
{
|
||||
"result": {
|
||||
"error": "ledgerIndexMalformed",
|
||||
"request": {
|
||||
"account": "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59",
|
||||
"command": "account_info",
|
||||
"ledger_index": "-",
|
||||
"strict": true
|
||||
},
|
||||
"status": "error"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
|
||||
|
||||
## WebSocketフォーマット
|
||||
|
||||
| `Field` | 型 | 説明 |
|
||||
|:----------|:---------|:------------------------------------------------------|
|
||||
| `id` | （場合により異なる） | この応答の要求元となったWeb Socket要求に指定されていたID |
|
||||
| `status` | 文字列 | `"error"` : 要求が原因でエラーが発生した場合 |
|
||||
| `type` | 文字列 | 通常は`"response"`。これは、コマンドに対し正常に応答したことを示します。 |
|
||||
| `error` | 文字列 | 発生したエラータイプの一意のコード。 |
|
||||
| `request` | オブジェクト | このエラーが発生した要求のコピー（JSONフォーマット）。**注意:** 要求にアカウントの機密情報が含まれている場合、ここにコピーされます。 |
|
||||
|
||||
|
||||
## JSON-RPCフォーマット
|
||||
|
||||
一部のJSON-RPC要求は、HTTPレイヤーでエラーコードで応答します。この場合、応答は応答本文にプレーンテキストで記述されます。たとえば`method`パラメーターでコマンドを指定し忘れた場合、応答は次のようになります。
|
||||
|
||||
```
|
||||
HTTP Status: 400 Bad Request
|
||||
Null method
|
||||
```
|
||||
|
||||
HTTPステータスコード200 OKが返されるその他のエラーの場合、応答はJSONフォーマットで、以下のフィールドが使用されます。
|
||||
|
||||
| `Field` | 型 | 説明 |
|
||||
|:-----------------|:-------|:-------------------------------------------------|
|
||||
| `result` | オブジェクト | クエリーに対する応答が含まれているオブジェクト |
|
||||
| `result.error` | 文字列 | 発生したエラータイプの一意のコード。 |
|
||||
| `result.status` | 文字列 | `"error"` : 要求が原因でエラーが発生した場合 |
|
||||
| `result.request` | オブジェクト | このエラーが発生した要求のコピー（JSONフォーマット）。**注意:** 要求にアカウントの機密情報が含まれている場合、ここにコピーされます。**注記:** 発行される要求にかかわらず、要求はWebSocketフォーマットに再設定されます。 |
|
||||
|
||||
|
||||
## 汎用エラー
|
||||
|
||||
すべてのメソッドは、以下のいずれかの値の`error`コードを返す可能性があります。
|
||||
|
||||
* `unknownCmd` - 要求に、`rippled`サーバーが認識する[コマンド](rippled-api.html)が含まれていません。
|
||||
* `jsonInvalid` -（WebSocketのみ）要求は適切なJSONオブジェクトではありません。
|
||||
* この場合JSON-RPCは、代わりに400 Bad Request HTTPエラーを返します。
|
||||
* `missingCommand` -（WebSocketのみ）要求に`command`フィールドが指定されていませんでした。
|
||||
* この場合JSON-RPCは、代わりに400 Bad Request HTTPエラーを返します。
|
||||
* `tooBusy` -サーバーの負荷が高すぎるため、現在このコマンドを実行できません。管理者として接続している場合は、通常このエラーが返されることはありません。
|
||||
* `noNetwork` - サーバーとXRP Ledgerピアツーピアネットワークのその他の部分との接続で問題が発生しています（サーバーがスタンドアロンモードで実行されていません）。
|
||||
* `noCurrent` - 高い負荷、ネットワークの問題、バリデータ障害、誤った構成、またはその他の問題が原因で、サーバーが現行のレジャーを認識できません。
|
||||
* `noClosed` - サーバーに閉鎖済みレジャーがありません。通常、このエラーは起動が完了していないことが原因で発生します。
|
||||
* `wsTextRequired` -（WebSocketのみ）要求の[opcode](https://tools.ietf.org/html/rfc6455#section-5.2)がテキストではありません。
|
||||
@@ -0,0 +1,5 @@
|
||||
# マーカーとページネーション
|
||||
|
||||
一部のメソッドから返されるデータは、1つの応答に実質的に収まらないことがあります。結果全体が収まらない場合、応答には`marker`フィールドが含まれます。このフィールドを使用することで、複数回の呼出しを通じてデータのページをさらに取得できます。各要求で直前の応答の`marker`値を渡して、終わったところから再開します。応答に`marker`が含まれていなければ、データセットの終わりに達しています。
|
||||
|
||||
`marker`フィールドのフォーマットは意図的に未定義になっています。各サーバーで`marker`をそれぞれに合わせて定義できるので、このフィールドの形式は文字列、ネストオブジェクトなどさまざまです。異なるサーバー、または同じサーバーの異なるメソッドでは、異なる`marker`定義を使用できます。各`marker`は一時的であり、10分以上経過すると予期されているとおりに機能しなくなることがあります。
|
||||
@@ -0,0 +1,15 @@
|
||||
# レジャーの変更
|
||||
|
||||
XRP Ledgerに対する変更はすべて、トランザクションの結果として行われます。XRP Ledgerの内容を変更できるAPIメソッドは、トランザクションを送信するコマンドだけです。Ledgerの内容が変更されても、その変更が永続的に適用されるのは、トランザクションが[コンセンサスプロセス](consensus.html)により承認されている場合に限られます。その他のほとんどのパブリックメソッドでは、異なる方法でXRP Ledgerに表示されるデータを閲覧し、サーバーの状態に関する情報を要求します。
|
||||
|
||||
トランザクション送信コマンド:
|
||||
|
||||
- [submitメソッド][]
|
||||
- [submit_multisignedメソッド][]
|
||||
|
||||
送信可能なさまざまなトランザクションについての詳細は、[トランザクションフォーマット](transaction-formats.html)を参照してください。
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -0,0 +1,70 @@
|
||||
# 要求フォーマット
|
||||
|
||||
## WebSocketフォーマット
|
||||
|
||||
`rippled`サーバーへのWebSocketを開いた後、以下の属性を使用して、コマンドを[JSON](https://en.wikipedia.org/wiki/JSON)オブジェクトとして送信できます。
|
||||
|
||||
* コマンド名を最上位の`"command"`フィールドに指定します。
|
||||
* このコマンドのすべての関連パラメーターも最上位に指定します。
|
||||
* オプションで、任意の値を指定した`"id"`フィールドを指定します。この要求への応答では、同一の`"id"`フィールドを使用します。そうすることで、応答が順不同で到達した場合も、どの要求によってどの応答を得られたのかがわかります。
|
||||
|
||||
応答はJSONオブジェクトとして返されます。
|
||||
|
||||
## JSON-RPCフォーマット
|
||||
|
||||
JSON-RPC要求を実行するには、`rippled`サーバーがJSON-RPC接続をリッスンしているポートおよびIPで、HTTP **POST**要求をルートパス（`/`）に送信します。HTTP/1.0またはHTTP/1.1を使用できます。HTTPSを使用する場合は、TLS v1.2を使用してください。セキュリティ上の理由から、`rippled`ではSSL v3以前を _サポートしていません_ 。
|
||||
|
||||
常に`Content-Type`ヘッダー（値`application/json`）を指定してください。
|
||||
|
||||
複数の要求を実行する予定の場合は、要求間で接続を閉じてから開く操作を行わずに済むように、[Keep-Alives](http://tools.ietf.org/html/rfc7230#section-6.3)を使用してください。
|
||||
|
||||
以下の属性を指定した要求本文を[JSON](https://en.wikipedia.org/wiki/JSON)オブジェクトとして送信します。
|
||||
|
||||
* コマンドを最上位の`"method"` フィールドに指定します。
|
||||
* 最上位の`"params"`フィールドを指定します。このフィールドの内容は、コマンドのすべてのパラメーターが指定された1つの入れ子JSONオブジェクトのみを保持している**1要素配列**です。
|
||||
|
||||
応答もJSONオブジェクトです。
|
||||
|
||||
## コマンドライン形式
|
||||
|
||||
コマンドラインでは、通常の（ダッシュが先頭に付いた）コマンドラインオプションの後にコマンドを指定し、その後に一連の限定的なパラメーターをスペースで区切って指定します。スペースやその他の特殊文字が含まれている可能性のあるパラメーター値は、一重引用符で囲みます。
|
||||
|
||||
### 要求の例
|
||||
|
||||
<!-- MULTICODE_BLOCK_START -->
|
||||
|
||||
*WebSocket*
|
||||
|
||||
```
|
||||
{
|
||||
"id": 2,
|
||||
"command": "account_info",
|
||||
"account": "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59",
|
||||
"strict": true,
|
||||
"ledger_index": "validated"
|
||||
}
|
||||
```
|
||||
|
||||
*JSON-RPC*
|
||||
|
||||
```
|
||||
POST http://s1.ripple.com:51234/
|
||||
{
|
||||
"method": "account_info",
|
||||
"params": [
|
||||
{
|
||||
"account": "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59",
|
||||
"strict": true,
|
||||
"ledger_index": "validated"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
*コマンドライン*
|
||||
|
||||
```
|
||||
rippled account_info r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59 validated true
|
||||
```
|
||||
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
@@ -0,0 +1,88 @@
|
||||
# 応答フォーマット
|
||||
|
||||
`rippled` APIからの応答のフォーマットは、メソッドが呼び出されたインターフェイス（WebSocket、JSON-RPC、コマンドライン）に応じて多少異なります。コマンドラインインターフェイスがJSON-RPCを呼び出すため、コマンドラインインターフェイスとJSON-RPCインターフェイスは同じフォーマットを使用します。
|
||||
|
||||
成功した場合の応答に含まれるフィールドは、以下の通りです。
|
||||
|
||||
| `Field` | 型 | 説明 |
|
||||
|:----------------|:---------|:------------------------------------------------|
|
||||
| `id` | （場合により異なる） | （WebSocketのみ）この応答の要求元となった要求で指定されているID。 |
|
||||
| `status` | 文字列 | （WebSocketのみ）値が`success`である場合、要求がサーバーによって正常に受信され、理解されたことを示します。 |
|
||||
| `result.status` | 文字列 | （JSON-RPCおよびコマンドライン）値が`success`である場合、要求がサーバーによって正常に受信され、理解されたことを示します。 |
|
||||
| `type` | 文字列 | （WebSocketのみ）値が`response`の場合、コマンドに対する正常な応答であることを示します。[非同期の通知](subscribe.html)では、`ledgerClosed`や`transaction`など異なる値が使用されます。 |
|
||||
| `result` | オブジェクト | クエリーの結果。内容はコマンドによって異なります。 |
|
||||
|
||||
|
||||
## 成功した場合の応答の例
|
||||
|
||||
<!-- MULTICODE_BLOCK_START -->
|
||||
|
||||
*WebSocket*
|
||||
|
||||
```
|
||||
{
|
||||
"id": 2,
|
||||
"status": "success",
|
||||
"type": "response",
|
||||
"result": {
|
||||
"account_data": {
|
||||
"Account": "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59",
|
||||
"Balance": "27389517749",
|
||||
"Flags": 0,
|
||||
"LedgerEntryType": "AccountRoot",
|
||||
"OwnerCount": 18,
|
||||
"PreviousTxnID": "B6B410172C0B65575D89E464AF5B99937CC568822929ABF87DA75CBD11911932",
|
||||
"PreviousTxnLgrSeq": 6592159,
|
||||
"Sequence": 1400,
|
||||
"index": "4F83A2CF7E70F77F79A307E6A472BFC2585B806A70833CCD1C26105BAE0D6E05"
|
||||
},
|
||||
"ledger_index": 6760970
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
*JSON-RPC*
|
||||
|
||||
```
|
||||
HTTP Status: 200 OK
|
||||
{
|
||||
"result": {
|
||||
"account_data": {
|
||||
"Account": "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59",
|
||||
"Balance": "27389517749",
|
||||
"Flags": 0,
|
||||
"LedgerEntryType": "AccountRoot",
|
||||
"OwnerCount": 18,
|
||||
"PreviousTxnID": "B6B410172C0B65575D89E464AF5B99937CC568822929ABF87DA75CBD11911932",
|
||||
"PreviousTxnLgrSeq": 6592159,
|
||||
"Sequence": 1400,
|
||||
"index": "4F83A2CF7E70F77F79A307E6A472BFC2585B806A70833CCD1C26105BAE0D6E05"
|
||||
},
|
||||
"ledger_index": 6761012,
|
||||
"status": "success"
|
||||
}
|
||||
}
|
||||
```
|
||||
*コマンドライン*
|
||||
|
||||
```
|
||||
{
|
||||
"result": {
|
||||
"account_data": {
|
||||
"Account": "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59",
|
||||
"Balance": "27389517749",
|
||||
"Flags": 0,
|
||||
"LedgerEntryType": "AccountRoot",
|
||||
"OwnerCount": 18,
|
||||
"PreviousTxnID": "B6B410172C0B65575D89E464AF5B99937CC568822929ABF87DA75CBD11911932",
|
||||
"PreviousTxnLgrSeq": 6592159,
|
||||
"Sequence": 1400,
|
||||
"index": "4F83A2CF7E70F77F79A307E6A472BFC2585B806A70833CCD1C26105BAE0D6E05"
|
||||
},
|
||||
"ledger_index": 6761012,
|
||||
"status": "success"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
@@ -0,0 +1,20 @@
|
||||
# rippledサーバーの状態
|
||||
|
||||
`rippled`サーバーの設定、稼働時間、その他の要素により、サーバーがグローバルなXRP Ledgerピアツーピアネットワークに参加する度合いは異なります。これは、[server_infoメソッド][]と[server_stateメソッド][]への応答内の`server_state`フィールドに示されます。応答は昇順のやり取りに従い、後の値は前の値より優先されます。これらの応答の定義を以下に示します（優先順位の高い順）。
|
||||
|
||||
| `Value` | 説明 |
|
||||
|:---------------|:------------------------------------------------------------|
|
||||
| `disconnected` | サーバーはXRP Ledgerピアツーピアネットワークにまったく接続されていません。オフラインモードで稼働しているか、何らかの理由でネットワークにアクセスできない可能性があります。 |
|
||||
| `connected` | サーバーはネットワークに接続されていると考えられます。 |
|
||||
| `syncing` | サーバーは現在、レジャーバージョンの状態に追いついていません。（通常、サーバーが始動後に最新状態になるまで数分かかります。） |
|
||||
| `tracking` | サーバーはネットワークに接続しています。 |
|
||||
| `full` | サーバーはネットワークに完全に組み込まれ、検証にも参加できますが、参加していません（検証者として設定されていないことが原因と考えられます）。 |
|
||||
| `validating` | サーバーは現在、レジャーの検証に参加しています。 |
|
||||
| `proposing` | サーバーはレジャーの検証に参加しており、現在、自身のバージョンを提案中です。 |
|
||||
|
||||
**注記:** `full`、`validating`、`proposing`の区別は、グローバルネットワークの他者との同期の状況に基づいていますが、通常サーバーの上記の状態は一般的なオペレーションの中で変動します。
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -0,0 +1,315 @@
|
||||
# シリアル化フォーマット
|
||||
[[ソース]<br>](https://github.com/ripple/rippled/blob/develop/src/ripple/protocol/impl/STObject.cpp#L696-L718 "Source")
|
||||
|
||||
このページでは、XRP Ledgerのトランザクションとその他のデータの正規バイナリフォーマットについて説明します。このバイナリフォーマットは、トランザクションの内容のデジタル署名を作成および検証するために必要であり、また他の用途にも使用されます。通常、[rippled API](rippled-api.html)はJSONを使用してクライアントアプリケーションと通信します。ただしJSONは、同じデータをさまざまな同等の方法で表現できるため、デジタル署名を付与するトランザクションをシリアル化するのに適したフォーマットではありません。
|
||||
|
||||
トランザクションをJSONまたはその他の表現から正規バイナリフォーマットへシリアル化するプロセスのステップを、以下にまとめます。
|
||||
|
||||
1. すべての必須フィールドが指定されていること（必須の[「自動入力可能」フィールド](transaction-common-fields.html#自動入力可能なフィールド)を含む）を確認します。
|
||||
|
||||
[トランザクションフォーマットリファレンス](transaction-formats.html)に、XRP Ledgerトランザクションの必須フィールドと省略可能なフィールドが定義されています。
|
||||
|
||||
**注記:**`SigningPubKey`もこのステップで指定する必要があります。署名の際に、署名用に指定されたシークレットキーからこのキーを生成できます。
|
||||
|
||||
2. 各フィールドのデータを[「内部」バイナリフォーマット](#内部フォーマット)に変換します。
|
||||
|
||||
3. フィールドを[正規順序](#フィールドの正規順序)でソートします。
|
||||
|
||||
4. 各フィールドの前に[フィールドID](#フィールドid)を付加します。
|
||||
|
||||
5. フィールド（プレフィクスを含む）をソート順に連結します。
|
||||
|
||||
その結果、ECDSA（secp256k1楕円曲線を使用）やEd25519などの既知の署名アルゴリズムを使用して署名できるバイナリブロブが1つ作成されます。XRP Ledgerのために、適切なプレフィクス（シングル署名の場合は`0x53545800`、マルチ署名の場合は`0x534D5400`）を使用してデータを[ハッシュ化][ハッシュ]する必要があります。署名後に、指定されている`TxnSignature`フィールドを使用してトランザクションを再度シリアル化する必要があります。 <!--{# TODO: link docs on how to compute a transaction signature. #}-->
|
||||
|
||||
**注記:** XRP Ledgerでは、[レジャーオブジェクト](ledger-object-types.html)や処理済みのトランザクションなど他のタイプのデータを表す場合にも同じシリアル化フォーマットが使用されます。ただし、署名されるトランザクションに追加するのに適切なフィールドは限られています。（たとえば署名自体が指定されている`TxnSignature`フィールドは、署名するバイナリブロブに含まれていてはなりません。）このように、「署名」フィールドとされてオブジェクトに署名するときにオブジェクトに含まれるフィールドもあれば、「非署名」とされてオブジェクトに含まれないフィールドもあります。
|
||||
|
||||
### 例
|
||||
|
||||
署名済みトランザクションと未署名のトランザクションはいずれも、JSONフォーマットとバイナリフォーマットの両方で表すことができます。同じ署名済みトランザクションのJSONフォーマットとバイナリフォーマットの例を以下に示します。
|
||||
|
||||
**JSON:**
|
||||
|
||||
```json
|
||||
{% include '_code-samples/tx-serialization/test-cases/tx1.json' %}
|
||||
```
|
||||
|
||||
**バイナリ（16進数として表現）:**
|
||||
|
||||
```text
|
||||
{% include '_code-samples/tx-serialization/test-cases/tx1-binary.txt' %}
|
||||
```
|
||||
|
||||
## サンプルコード
|
||||
|
||||
ここで説明するシリアル化プロセスは複数の場所にさまざまなプログラミング言語で実装されています。
|
||||
|
||||
- C++: [`rippled` コードベース](https://github.com/ripple/rippled/blob/develop/src/ripple/protocol/impl/STObject.cpp)
|
||||
- JavaScript: [`ripple-binary-codec`](https://github.com/ripple/ripple-binary-codec/) パッケージ
|
||||
- Python 3: [このリポジトリのコードサンプルセクション]({{target.github_forkurl}}/blob/{{target.github_branch}}/content/_code-samples/tx-serialization/serialize.py)
|
||||
|
||||
これらのすべての実装には、一般利用が可能なオープンソースライセンスが提供されているので、学習のためにドキュメントと合わせて使用するだけでなく、必要に応じてコードをインポート、使用、または変更することができます。
|
||||
|
||||
|
||||
|
||||
## 内部フォーマット
|
||||
|
||||
各フィールドには「内部」バイナリフォーマットがあります。このフォーマットは、`rippled`ソースコードで署名時に（およびその他のほとんどの場合に）そのフィールドを表示するのに使用されます。すべてのフィールドの内部フォーマットは、[`SField.cpp`](https://github.com/ripple/rippled/blob/master/src/ripple/protocol/impl/SField.cpp)のソースコードに定義されています。（このフィールドには、トランザクションフィールド以外のフィールドも含まれています。）[トランザクションフォーマットリファレンス](transaction-formats.html)にも、すべてのトランザクションフィールドの内部フォーマットが記載されています。
|
||||
|
||||
たとえば`Flags` [共通トランザクションフィールド](transaction-common-fields.html)はUInt32（32ビット符号なし整数）になります。
|
||||
|
||||
### 定義ファイル
|
||||
|
||||
以下のJSONファイルには、XRP Ledgerデータをそのバイナリフォーマットにシリアル化し、バイナリからシリアル化解除するのに必要な重要な定数が定義されています。
|
||||
|
||||
**<https://github.com/ripple/ripple-binary-codec/blob/master/src/enums/definitions.json>**
|
||||
|
||||
この定義ファイルの最上位フィールドの定義を以下の表に示します。
|
||||
|
||||
| フィールド | 内容 |
|
||||
|:----------------------|:-----------------------------------------------------|
|
||||
| `TYPES` | フィールドIDの作成と正規順序でのフィールドのソートのためのデータタイプからその[「タイプコード」](#タイプコード)へのマップ。1未満のコードは実際のデータには含まれません。10000を超えるコードは、他のオブジェクト内部ではシリアル化できない「トランザクション」などの特殊な「上位」オブジェクトタイプを表します。各タイプのシリアル化方法についての詳細は、[タイプリスト](#タイプリスト)を参照してください。 |
|
||||
| `LEDGER_ENTRY_TYPES` | [レジャーオブジェクト](ledger-object-types.html)から対応するデータタイプへのマップ。これはレジャー状態データと、処理されたトランザクションの[メタデータ](transaction-metadata.html)の「affected nodes」セクションに含まれます。 |
|
||||
| `FIELDS` | トランザクション、レジャーオブジェクト、あるいはその他のデータに含まれる可能性があるすべてのフィールドを表すタプルからなるソート済み配列。各タプルの1番目のメンバーはフィールドの文字列名であり、2番目のメンバーはそのフィールドのプロパティーが含まれているオブジェクトです。（これらのフィールドの定義については、以下の「フィールドプロパティー」の表を参照してください。） |
|
||||
| `TRANSACTION_RESULTS` | [トランザクション結果コード](transaction-results.html)から対応する数値へのマップ。レジャーに含まれない結果タイプにはマイナスの値が含まれています。`tesSUCCESS`に数値0が含まれています。[`tec`クラスコード](tec-codes.html)は、レジャーに含まれている失敗を示しています。 |
|
||||
| `TRANSACTION_TYPES` | [トランザクションのタイプ](transaction-types.html)から対応する数値へのマップ。 |
|
||||
|
||||
署名と送信のためにトランザクションをシリアル化するという目的から、`FIELDS`、`TYPES`、および`TRANSACTION_TYPES`フィールドが必要です。
|
||||
|
||||
`FIELDS`配列のフィールド定義オブジェクトには以下のフィールドが含まれています。
|
||||
|
||||
| フィールド | 型 | 内容 |
|
||||
|:-----------------|:--------|:------------------------------------------------|
|
||||
| `nth` | 数値 | このフィールドの[フィールドコード](#フィールドコード)。このコードは、[フィールドID](#フィールドid)の作成時と、同一データタイプの他のフィールドとのソート時に使用されます。 |
|
||||
| `isVLEncoded` | ブール値 | `true`の場合、このフィールドには[長さプレフィクスが付加されています](#長さプレフィクスを付加する)。 |
|
||||
| `isSerialized` | ブール値 | `true`の場合、このフィールドはシリアル化バイナリデータにエンコードされる必要があります。このフィールドが`false`の場合、一般にフィールドは保管されず、オンデマンドで再作成されます。 |
|
||||
| `isSigningField` | ブール値 | `true`の場合、署名のためにトランザクションを準備する際にこのフィールドをシリアル化する必要があります。`false`の場合、このフィールドは署名対象データから省略する必要があります。（これはトランザクションに含まれていない可能性があります。） |
|
||||
| `type` | 文字列 | このフィールドの内部データタイプ。これは、このフィールドの[タイプコード](#タイプコード)を示す`TYPES`マップのキーにマップします。 |
|
||||
|
||||
### フィールドID
|
||||
|
||||
[[ソース - エンコード]](https://github.com/seelabs/rippled/blob/cecc0ad75849a1d50cc573188ad301ca65519a5b/src/ripple/protocol/impl/Serializer.cpp#L117-L148 "Source")
|
||||
[[ソース - デコード]](https://github.com/seelabs/rippled/blob/cecc0ad75849a1d50cc573188ad301ca65519a5b/src/ripple/protocol/impl/Serializer.cpp#L484-L509 "Source")
|
||||
|
||||
フィールドのタイプコードとフィールドコードを結合すると、フィールドの一意のIDになります。このIDは、最終的なシリアル化ブロブでこのフィールドの前に付加されます。フィールドIDのサイズは、タイプコードとその結合対象のフィールドコードに応じて1～3バイトとなります。以下の表を参照してください。
|
||||
|
||||
| | タイプコード < 16 | タイプコード >= 16 |
|
||||
|:-----------------|:------------------------------------------------------------------------------|:--|
|
||||
| **フィールドコード < 16** |  |  |
|
||||
| **フィールドコード >= 16** |  |  |
|
||||
|
||||
デコードの際には、**1番目のバイト**のどのビットがゼロであるかによって、フィールドIDのバイト数を把握できます。これは、上記の表の例に対応しています。
|
||||
|
||||
| | 上位4ビットがゼロ以外である | 上位4ビットがゼロである |
|
||||
|:-----------------|:------------------------------------------------------------------------------|:--|
|
||||
| **下位4ビットがゼロ以外である** | 1バイト: 上位4ビットがタイプを定義し、下位4ビットがフィールドを定義します。 | 2バイト: 1番目のバイトの下位4ビットがフィールドを定義し、次のバイトがタイプを定義します。 |
|
||||
| **下位4ビットがゼロである** | 2バイト: 1番目のバイトの上位4ビットがタイプを定義し、1番目のバイトの下位4ビットは0になります。次のバイトがフィールドを定義します。 | 3バイト: 1番目のバイトは0x00、2番目のバイトはタイプを定義します。3番目のバイトはフィールドを定義します。 |
|
||||
|
||||
**注意:** フィールドIDは、フィールドのソートに使用される2つの要素で構成されますが、シリアル化されたフィールドID自体に基づいてソートを実行しないでください。これは、フィールドIDのバイト構造によってソート順序が変わるためです。
|
||||
|
||||
### 長さプレフィクスを付加する
|
||||
|
||||
一部の可変長フィールドの前には、長さインディケーターが付加されています。`Blob`フィールド（任意のバイナリデータを含む）がこれに該当します。長さプレフィクスが付加されているタイプのリストについては、[タイプリスト](#タイプリスト)の表を参照してください。
|
||||
|
||||
**注記:** 一部のタイプの可変長フィールドには、長さプレフィクスが付加されません。このようなタイプでは、他の方法で内容の終わりが示されます。
|
||||
|
||||
長さプレフィクスはフィールドの長さを示す1～3バイトで構成され、タイププレフィクスと内容の間に挿入されます。
|
||||
|
||||
- フィールドに0～192バイトのデータが含まれている場合、1番目のバイトは内容の長さを示し、長さバイトの直後にそのバイト数のデータが続きます。
|
||||
|
||||
- フィールドに193～12480バイトのデータが含まれている場合、最初の2バイトは以下の式で算出されるフィールドの長さを示します。
|
||||
|
||||
193 + ((byte1 - 193) * 256) + byte2
|
||||
|
||||
- フィールドに12481～918744バイトのデータが含まれている場合、最初の3バイトは以下の式で算出されるフィールドの長さを示します。
|
||||
|
||||
12481 + ((byte1 - 241) * 65536) + (byte2 * 256) + byte3
|
||||
|
||||
- 長さプレフィクスが付加されているフィールドに格納できる最大データは918744バイトです。
|
||||
|
||||
デコード時に、1番目の長さバイトの値から、追加の長さバイト（0、1、または2）が存在するかどうかを把握できます。
|
||||
|
||||
- 1番目の長さバイトの値が192以下の場合、これは唯一の長さバイトであり、フィールドの内容の長さはこのバイトが示すバイト数です。
|
||||
- 1番目の長さバイトの値が193～240の場合、2つの長さバイトがあります。
|
||||
- 1番目の長さバイトの値が241～254の場合、3つの長さバイトがあります。
|
||||
|
||||
|
||||
## フィールドの正規順序
|
||||
|
||||
トランザクションのすべてのフィールドは、まずフィールドのタイプ（特に各タイプに割り当てられている数値の「タイプコード」）に基づいて特定の順序でソートされ、次にフィールド自体（「フィールドコード」）に基づいてソートされます。（たとえば、姓がフィールドのタイプ、名前がフィールド自体とすると、姓で最初にソートし、次に名でソートすることになります。）
|
||||
|
||||
### タイプコード
|
||||
|
||||
各フィールドタイプには任意のタイプコードが含まれており、番号が小さいコードから最初にソートされます。これらのコードは[`SField.h`](https://github.com/ripple/rippled/blob/master/src/ripple/protocol/SField.h#L57-L74)で定義されています。
|
||||
|
||||
たとえば [UInt32のタイプコードが2である](https://github.com/ripple/rippled/blob/72e6005f562a8f0818bc94803d222ac9345e1e40/src/ripple/protocol/SField.h#L59)ので、すべてのUInt32フィールドは、すべての[Amountフィールド（タイプコード6）](https://github.com/ripple/rippled/blob/72e6005f562a8f0818bc94803d222ac9345e1e40/src/ripple/protocol/SField.h#L63)よりも前に位置します。
|
||||
|
||||
[定義ファイル](#定義ファイル)には、`TYPES`マップの各タイプのタイプコードがリストされています。
|
||||
|
||||
### フィールドコード
|
||||
|
||||
各フィールドにはフィールドコードが含まれています。フィールドコードは、同じタイプのフィールドをソートするときに使用され、番号が小さいコードが最初になるようにソートされます。これらのフィールドは[`SField.cpp`](https://github.com/ripple/rippled/blob/72e6005f562a8f0818bc94803d222ac9345e1e40/src/ripple/protocol/impl/SField.cpp#L72-L266)で定義されています。
|
||||
|
||||
たとえば[Paymentトランザクション][]の`Account`フィールドの[ソートコードが1である](https://github.com/ripple/rippled/blob/72e6005f562a8f0818bc94803d222ac9345e1e40/src/ripple/protocol/impl/SField.cpp#L219)場合、このフィールドは`Destination`フィールド（[ソートコードが3である](https://github.com/ripple/rippled/blob/72e6005f562a8f0818bc94803d222ac9345e1e40/src/ripple/protocol/impl/SField.cpp#L221)フィールド）よりも前に位置します。
|
||||
|
||||
フィールドコードは異なるフィールドタイプのフィールドで再利用されますが、同じタイプのフィールドに同じフィールドコードが含まれることはありません。タイプコードとフィールドコードを組み合わせると、フィールドの一意の[フィールドID](#フィールドid)になります。
|
||||
|
||||
|
||||
|
||||
## タイプリスト
|
||||
|
||||
トランザクションの指示には、以下のタイプのフィールドを指定できます。
|
||||
|
||||
| タイプ名 | タイプコード | ビット長 | [長さプレフィクスが付加されるか]? | 説明 |
|
||||
|:--------------|:----------|:-----------|:-------------------|----------------|
|
||||
| [AccountID][] | 8 | 160 | はい | [アカウント](accounts.html)の一意のID。 |
|
||||
| [Amount][] | 6 | 64または384 | いいえ | XRPまたは発行済み通貨の額。フィールドの長さは、XRPの場合は64ビット、発行済み通貨の場合は384ビット（64+160+160）です。 |
|
||||
| [Blob][] | 7 | 可変 | はい | 任意のバイナリデータ。このようなフィールドの中で重要なフィールドとして、`TxnSignature`（トランザクションを承認する署名）があります。 |
|
||||
| [Hash128][] | 4 | 128 | いいえ | 128ビットの任意のバイナリ値。該当する唯一のフィールドは`EmailHash`です。これは、[Gravatar](https://www.gravatar.com/)を取得する目的でアカウント所有者のメールのMD-5ハッシュを保管するフィールドです。 |
|
||||
| [Hash160][] | 17 | 160 | いいえ | 160ビットの任意のバイナリ値。これにより通貨コードまたはイシュアーが定義されます。 |
|
||||
| [Hash256][] | 5 | 256 | いいえ | 256ビットの任意のバイナリ値。これは通常、トランザクション、レジャーバージョン、またはレジャーデータオブジェクトの「SHA-512Half」ハッシュを表します。 |
|
||||
| [PathSet][] | 18 | 可変 | いいえ | [複数通貨間ペイメント](cross-currency-payments.html)の有効な[ペイメントパス](paths.html)のセット。 |
|
||||
| [STArray][] | 15 | 可変 | いいえ | 可変数のメンバーからなる配列。フィールドによってタイプが異なる場合があります。この例として、[memos](transaction-common-fields.html#memosフィールド)や[マルチ署名](multi-signing.html)で使用される署名者のリストがあります。 |
|
||||
| [STObject][] | 14 | 可変 | いいえ | 1つ以上のネストされたフィールドを含むオブジェクト。 |
|
||||
| [UInt8][] | 16 | 8 | いいえ | 8ビットの符号なし整数。 |
|
||||
| [UInt16][] | 1 | 16 | いいえ | 16ビットの符号なし整数。`TransactionType`は、このタイプの特殊なフィールドで、特定の文字列から整数値へのマッピングを含みます。 |
|
||||
| [UInt32][] | 2 | 32 | いいえ | 32ビットの符号なし整数。このタイプの例として、すべてのトランザクションの`Flags`フィールドと`Sequence`フィールドがあります。 |
|
||||
|
||||
[長さプレフィクスを付加する]: #長さプレフィクスを付加する
|
||||
|
||||
上記のフィールドタイプの他に、[レジャーオブジェクト](ledger-object-types.html)や[トランザクションメタデータ](transaction-metadata.html)などのコンテキストでは以下のタイプが含まれることがあります。
|
||||
|
||||
| タイプ名 | タイプコード | [長さプレフィクスを付加する]? | 説明 |
|
||||
|:------------|:----------|:-------------------|:------------------------------|
|
||||
| Transaction | 10001 | いいえ | [トランザクション](transaction-formats.html)全体を含む「上位」タイプ。 |
|
||||
| LedgerEntry | 10002 | いいえ | [レジャーオブジェクト](ledger-object-types.html)全体を含む「上位」タイプ。 |
|
||||
| Validation | 10003 | いいえ | ピアツーピア通信で[コンセンサスプロセス](consensus.html)の検証投票を表すために使用される「上位」タイプ。 |
|
||||
| Metadata | 10004 | いいえ | [1つのトランザクションのメタデータ](transaction-metadata.html)を含む「上位」タイプ。 |
|
||||
| [UInt64][] | 3 | いいえ | 64ビットの符号なし整数。このタイプはトランザクションの指示には含まれませんが、さまざまなレジャーオブジェクトでこのタイプのフィールドが使用されます。 |
|
||||
| Vector256 | 19 | はい | このタイプはトランザクションの指示には含まれませんが、[Amendmentsレジャーオブジェクト](amendments-object.html)の`Amendments`フィールドでは、現在有効な[Amendment](amendments.html)を示すためにこのタイプが使用されます。 |
|
||||
|
||||
|
||||
### AccountIDフィールド
|
||||
[AccountID]: #accountidフィールド
|
||||
|
||||
このタイプのフィールドには、XRP Ledger[アカウント](accounts.html)の160ビットのIDが含まれています。JSONではこれらのフィールドは[base58][] XRP Ledger「アドレス」および追加のチェックサムデータとして表示されます。このため、スペルミスが有効なアドレスとなることがありません。（このエンコードは「Base58Check」とも呼ばれ、誤ったアドレスへの送金を防止します。）これらのフィールドのバイナリフォーマットにはチェックサムデータは含まれておらず、また[アドレスのbase58エンコード](accounts.html#アドレスのエンコード)で使用される`0x00`「タイププレフィクス」も含まれていません。（ただし、バイナリフォーマットは主に署名済みトランザクションに使用されるため、署名済みトランザクションを転記する際にスペルミスなどのエラーが発生すると署名が無効となり、送金できなくなります。）
|
||||
|
||||
スタンドアロンフィールドとして表示されるAccountID（`Account`や`Destination`など）の長さは固定長の160ビットですが、[長さプレフィクスが付加](#長さプレフィクスを付加する)されます。その結果、これらのフィールドの長さインディケーターは常に`0x14`バイトになります。特殊フィールドの子として示されるAccountID（[Amount `issuer`][Amount]、[PathSet `account`][PathSet]など）では長さプレフィクスは付加 _されません_ 。
|
||||
|
||||
|
||||
### Amountフィールド
|
||||
[Amount]: #amountフィールド
|
||||
|
||||
「Amount」タイプは、通貨（XRPまたは発行済み通貨）の額を表す特殊なフィールドタイプです。このタイプは2つのサブタイプで構成されます。
|
||||
|
||||
- **XRP**
|
||||
|
||||
XRPは64ビット符号なし整数（ビッグエンディアンオーダー）としてシリアル化されます。ただし、XRPであることを示すため最上位ビットが常に0であり、プラスの値であることを示す最上位から2番目のビットは1となります。XRPの最大額（10<sup>17</sup> drop）には57ビットが必要であるため、XRPのシリアル化フォーマットを計算するには、標準の64ビット符号なし整数をとり、`0x4000000000000000`のビットOR演算を行います。
|
||||
|
||||
- **発行済み通貨**
|
||||
|
||||
発行済み通貨は以下の3つのセグメントで構成され、セグメントの順序は以下のとおりです。
|
||||
|
||||
1. [内部通貨フォーマット](currency-formats.html#発行済み通貨の計算)の額を示す64ビット。1番目のビットは、これがXRPではないことを示す`1`です。
|
||||
2. [通貨コード][]を示す160ビット。標準APIでは、[標準通貨コードフォーマット](currency-formats.html#標準通貨コード)を使用して「USD」などの3文字のコードが160ビットのコードに変換されますが、160ビットのカスタムコードも使用できます。
|
||||
3. イシュアーのアカウントIDを示す160ビット。（関連項目: [アカウントアドレスエンコード](accounts.html#アドレスのエンコード))
|
||||
|
||||
1番目のビットに基づいて2つのサブタイプのいずれに該当するかを確認できます。`0`の場合はXRP、`1`の場合は発行済み通貨です。
|
||||
|
||||
以下の図に、XRPの額と発行済み通貨の額のシリアル化フォーマットを示します。
|
||||
|
||||
|
||||
|
||||
|
||||
### 配列フィールド
|
||||
[STArray]: #配列フィールド
|
||||
|
||||
一部のトランザクションフィールド（[SignerListSetトランザクション][]の`SignerEntries`や[`Memos`](transaction-common-fields.html#memosフィールド)など）はオブジェクトの配列です（「STArray」タイプと呼ばれます）。
|
||||
|
||||
配列には、さまざまな[オブジェクトフィールド](#オブジェクトフィールド)がそのネイティブバイナリフォーマットで特定の順序で含まれています。JSONでは、各配列メンバーが1つのフィールド（メンバーオブジェクトフィールドの名前）を含むJSON「ラッパー」オブジェクトです。そのフィールドの値は（「内部」）オブジェクト自体です。
|
||||
|
||||
バイナリフォーマットでは、配列の各メンバーにはフィールドIDプレフィクス（ラッパーオブジェクトの単一キーに基づく）と内容（[オブジェクトとしてシリアル化された](#オブジェクトフィールド)内部オブジェクトからなる）が含まれています。配列の終わりをマークするため、アイテムにフィールドID `0xf1`（配列のタイプコードとフィールドコード1）を付加し、内容は指定しません。
|
||||
|
||||
以下の例は、配列のシリアル化フォーマットを示します（`SignerEntries`フィールド）。
|
||||
|
||||
|
||||
|
||||
|
||||
### ブロブフィールド
|
||||
[Blob]: #ブロブフィールド
|
||||
|
||||
ブロブタイプは、任意のデータを持つ[長さプレフィクスが付加されている](#長さプレフィクスを付加する)フィールドです。このタイプを使用する2種類の一般的なフィールドとして、`SigningPubKey`と`TxnSignature`があります。これらのフィールドにはそれぞれ、トランザクションの実行を承認する公開鍵と署名が含まれています。
|
||||
|
||||
両方のフィールドにはこれ以上の内容構造がないため、フィールドIDと長さプレフィクスの後に可変長エンコードで示される正確なバイト数で構成されます。
|
||||
|
||||
|
||||
### ハッシュフィールド
|
||||
[Hash128]: #ハッシュフィールド
|
||||
[Hash160]: #ハッシュフィールド
|
||||
[Hash256]: #ハッシュフィールド
|
||||
|
||||
XRP LedgerのハッシュタイプにはHash128、Hash160、Hash256があります。これらのフィールドには特定のビット数のバイナリデータが含まれており、それらのデータはハッシュ演算の結果を表す場合とそうでない場合があります。
|
||||
|
||||
これらのフィールドは、長さインディケーターを使用せずに、ビッグエンディアンバイトオーダーで特定数のビットとしてシリアル化されます。
|
||||
|
||||
|
||||
### オブジェクトフィールド
|
||||
[STObject]: #オブジェクトフィールド
|
||||
|
||||
トランザクションフィールドの一部（[SignerListSetトランザクション][]の`SignerEntry`や`Memos`配列の`Memo`など）はオブジェクトです（「STObject」タイプと呼ばれます）。オブジェクトのシリアル化は配列のシリアル化に似ていますが、唯一異なる点としてオブジェクトフィールド内では**オブジェクトのメンバーを正規順序に従って配置する必要がある**点があげられます。配列フィールドではすでに順序が明示的に設定されています。
|
||||
|
||||
オブジェクトフィールドの[正規フィールド順序](#フィールドの正規順序)は、すべての最上位フィールドの正規フィールド順序と同じですが、オブジェクトのメンバーはオブジェクト内でソートする必要があります。最終メンバーの後には、「オブジェクトの終わり」を示すフィールドID（`0xe1`）があり、このフィールドには内容がありません。
|
||||
|
||||
以下の例は、オブジェクトのシリアル化フォーマットを示します（`Memos`配列内の1つの`Memo`オブジェクト）。
|
||||
|
||||
|
||||
|
||||
|
||||
### PathSetフィールド
|
||||
[PathSet]: #pathsetフィールド
|
||||
|
||||
複数通貨間[Paymentトランザクション][]の`Paths`フィールドは、JSONで配列からなる配列として表される「PathSet」です。使用されるパスについての詳細は、[パス](paths.html)を参照してください。
|
||||
|
||||
PathSetは、**1～6**の個別パスとして順序どおりにシリアル化されます[[ソース]](https://github.com/ripple/rippled/blob/4cff94f7a4a05302bdf1a248515379da99c5bcd4/src/ripple/app/tx/impl/Payment.h#L35-L36 "Source")。それぞれの完全なパスの後には、パスの後に続く内容を示すバイトが配置されます。
|
||||
|
||||
- `0xff` は別のパスが続くことを示します。
|
||||
- `0x00` はPathSetの終わりを示します。
|
||||
|
||||
各パスには**1～8**のパスステップがこの順序で含まれています[[ソース]](https://github.com/ripple/rippled/blob/4cff94f7a4a05302bdf1a248515379da99c5bcd4/src/ripple/app/tx/impl/Payment.h#L38-L39 "Source")。各ステップは**タイプ**を示すバイトで始まり、その後にパスステップを記述する1つ以上のフィールドが続きます。タイプは、ビット単位のフラグを使用してそのパスステップに含まれるフィールドを示します。（たとえば値が`0x30`の場合、通貨とイシュアーの両方が変更されます。）複数のフィールドが含まれている場合、フィールドは常に特定の順序で配置されます。
|
||||
|
||||
以下の表に、有効なフィールドと、タイプバイトでフィールドを示すために設定されるビット単位のフラグを示します。
|
||||
|
||||
| タイプフラグ | 含まれるフィールド | フィールドタイプ | ビットサイズ | 順序 |
|
||||
|:----------|:--------------|:------------------|:---------|:------|
|
||||
| `0x01` | `account` | [AccountID][] | 160ビット | 1番目 |
|
||||
| `0x10` | `currency` | [通貨コード][] | 160ビット | 2番目 |
|
||||
| `0x20` | `issuer` | [AccountID][] | 160ビット | 3番目 |
|
||||
|
||||
[通貨コード]: currency-formats.html#標準通貨コード
|
||||
|
||||
いくつかの組み合わせは無効です。詳細は、[パスの仕様](paths.html#パスの仕様)を参照してください。
|
||||
|
||||
`account`フィールドと`issuer`フィールドのAccountIDには、長さプレフィクスは付加 _されていません_ 。`currency`がXRPの場合、通貨コードは160ビットのゼロとして表されます。
|
||||
|
||||
各ステップの直後にはパス上の次のステップが続きます。前述したように、パスの最終ステップの後には`0xff`（別のパスが続く場合）または`0x00`（これが最終パスの終わりの場合）が続きます。
|
||||
|
||||
以下の例は、PathSetのシリアル化フォーマットを示します。
|
||||
|
||||
|
||||
|
||||
|
||||
### UIntフィールド
|
||||
[UInt8]: #uintフィールド
|
||||
[UInt16]: #uintフィールド
|
||||
[UInt32]: #uintフィールド
|
||||
[UInt64]: #uintフィールド
|
||||
|
||||
XRP Ledgerには符号なし整数タイプUInt8、UInt16、UInt32、UInt64があります。これらのタイプはすべて、指定されたビット数の標準ビッグエンディアンバイナリー符号なし整数です。
|
||||
|
||||
JSONオブジェクトにこれらのフィールドが含まれている場合、ほとんどはデフォルトでJSONの数値として表されます。例外として、UInt64は文字列として表されます。これは、一部のJSONデコーダーがこれらの整数を64ビットの「倍精度」浮動小数点数として表現しようとするためです。64ビットの「倍精度」浮動小数点数では、すべてのUInt64値を完全な精度で表現することができません。
|
||||
|
||||
もう1つの特殊なケースとして`TransactionType`フィールドがあります。JSONではこのフィールドは便宜上、トランザクションタイプの名前の文字列として表現されますが、バイナリではこのフィールドはUInt16です。[定義ファイル](#定義ファイル)内の`TRANSACTION_TYPES`オブジェクトにより、これらの文字列が特定の数値にマップされます。
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
167
content/references/rippled-api/commandline-usage.ja.md
Normal file
167
content/references/rippled-api/commandline-usage.ja.md
Normal file
@@ -0,0 +1,167 @@
|
||||
# rippledコマンドライン使用リファレンス
|
||||
|
||||
`rippled`実行可能ファイルは、通常はXRP Ledgerを処理するデーモンとして実行されますが、他のモードでも実行できます。このページでは、コマンドラインから実行する場合に`rippled`に渡すことができるすべてのオプションを説明します。
|
||||
|
||||
## 使用できるモード
|
||||
|
||||
- **デーモンモード** - デフォルトです。XRP Ledgerに接続して、トランザクションを処理し、レジャーデータベースを構築します。
|
||||
- **スタンドアロンモード** - `-a`または`--standalone`オプションを使用します。他のサーバーには接続できない以外は、デーモンモードと同様です。このモードは、トランザクション処理やその他の機能のテストに使用できます。
|
||||
- **クライアントモード** - APIメソッドの名前を指定して、別の`rippled`サーバーにJSON-RPCクライアントとして接続し、その後終了します。実行可能ファイルがすでに別のプロセスで実行中である場合に、このモードを使用してサーバーのステータスとレジャーデータを確認できます。
|
||||
- **その他の使用法** - 以下の各コマンドを実行すると、`rippled`実行可能ファイルが何らかの情報を出力し、その後終了します。
|
||||
- **ヘルプ** - 使用法の説明を出力するには、`-h`または`--help`を使用します。
|
||||
- **単体テスト** - 単体テストを実行し、結果の概要を出力するには、`-u`または`--unittest`を使用します。rippledが正しくコンパイルされていることを確認する場合に便利です。
|
||||
- **バージョンステートメント** - `rippled`のバージョン番号を出力し、その後終了するには、`--version`を使用します。
|
||||
|
||||
## 汎用オプション
|
||||
|
||||
ほとんどのモードに適用されるオプションは、以下の通りです。
|
||||
|
||||
| オプション | 説明 |
|
||||
|:----------------|:-----------------------------------------------------------|
|
||||
| `--conf {FILE}` | デフォルトのロケーションで構成ファイルを検索する代わりに、構成ファイルとして`{FILE}`を使用します。指定されていない場合、`rippled`は最初にローカル作業ディレクトリで`rippled.cfg`ファイルがあるかどうかを調べます。Linuxでは、このファイルが見つからない場合`rippled`は次に`$XDG_CONFIG_HOME/ripple/ripple.cfg`を確認します。（一般的に`$XDG_CONFIG_HOME`の場所は`$HOME/.config`です。） |
|
||||
|
||||
### 詳細レベルのオプション
|
||||
|
||||
次の汎用オプションは、標準出力とログファイルに書き込まれる情報の量を制御します。
|
||||
|
||||
| オプション | 短縮形 | 説明 |
|
||||
|:------------|:--------------|:-----------------------------------------------|
|
||||
| `--debug` | | **廃止予定** トレースレベルのデバッグを有効にします（`--verbose`のエイリアス）。代わりに[log_levelメソッド][]を使用してください。 |
|
||||
| `--silent` | | 起動中にログを標準出力と標準エラー出力に書き込みません。冗長なログを削減するために`rippled`をsystemdユニットとして開始する場合に推奨されます。 |
|
||||
| `--verbose` | `-v` | **廃止予定** トレースレベルデバッグを有効にします。代わりに[log_levelメソッド][]を使用してください。 |
|
||||
|
||||
|
||||
|
||||
## デーモンモードのオプション
|
||||
|
||||
```bash
|
||||
rippled [OPTIONS]
|
||||
```
|
||||
|
||||
デーモンモードは、`rippled`のデフォルトの運用モードです。[汎用オプション](#汎用オプション)の他に、以下のいずれかのオプションを指定できます。
|
||||
|
||||
| オプション | 説明 |
|
||||
|:--------------------|:-------------------------------------------------------|
|
||||
| `--fg` | デーモンをフォアグラウンドでシングルプロセスとして実行します。このオプションを指定しない場合、`rippled`は1番目のプロセスがモニターとして実行されている間に、デーモンの2番目のプロセスをフォークします。 |
|
||||
| `--import` | 完全に起動する前に、別の`rippled`サーバーのレジャーストアーからレジャーデータをインポートしてください。構成ファイルに有効な`[import_db]`スタンザが指定されている必要があります。 |
|
||||
| `--net` | **廃止予定** デバッグのためのオプションです。ネットワークからレジャーを取得できるようになるまで、ローカルレジャーを作成しません。 |
|
||||
| `--nodetoshard` | 完全に起動する前に、すべての完全な[履歴シャード](history-sharding.html)をレジャーストアーからシャードストアーにコピーしてください（シャードストアーに設定されている最大ディスク容量まで）。CPUとI/Oを大量に使用します。注意: このコマンドは、データを（移動するのではなく）コピーするため、シャードストアーとレジャーストアーの両方にデータを保存するのに十分なディスク容量が必要です。 <!--{# Task for writing a tutorial to use this: DOC-1639 #}--> |
|
||||
| `--quorum {QUORUM}` | これは[テストネットワーク](parallel-networks.html)のブートストラップ用のオプションです。検証のための最小定数をオーバーライドするには、`{QUORUM}`の信頼できるバリデータの同意を必要とします。デフォルトでは、検証のための定数は、信頼できるバリデータの実際の数に基づき、安全な数に自動的に設定されます。一部のバリデータがオンラインではない場合、このオプションにより、標準定数よりも少ない数のバリデータで続行できるようになります。**警告:** 定数を手動で設定すると、設定した値が小さすぎるためにサーバーがネットワークの他の部分から分岐することを防ぐことができない可能性があります。このオプションは、コンセンサスを十分に理解し、標準以外の設定を使用する必要がある場合にのみ使用してください。 |
|
||||
| `--validateShards` | シャードストアーのデータが有効であり、ネットワーク履歴と整合性があることを確認してください。シャードストアーの詳細は、[履歴シャーディング](history-sharding.html)を参照してください。 |
|
||||
|
||||
## スタンドアロンモードのオプション
|
||||
|
||||
```bash
|
||||
rippled --standalone [OPTIONS]
|
||||
rippled -a [OPTIONS]
|
||||
```
|
||||
スタンドアロンモードで実行します。このモードでは、`rippled`はネットワークに接続しないか、またはコンセンサスを実行しません。（それ以外の場合、`rippled`はデーモンモードで実行されます。）
|
||||
|
||||
### 初期レジャーオプション
|
||||
|
||||
以下のオプションにより、起動時に最初に読み込むレジャーが判断されます。これらはのオプションは、履歴レジャーのリプレイまたはテストネットワークのブートストラップのためのものです。
|
||||
|
||||
| オプション | 説明 |
|
||||
|:----------------------|:-----------------------------------------------------|
|
||||
| `--ledger {LEDGER}` | `{LEDGER}`（レジャーハッシュまたはレジャーインデックス）により初期レジャーと識別されているレジャーバージョンを読み込みます。指定されたレジャーバージョンは、サーバーのレジャーストアーに格納される必要があります。 |
|
||||
| `--ledgerfile {FILE}` | 指定された`{FILE}`からレジャーバージョンを読み込みます（このファイルには完全なレジャーがJSONフォーマットで格納されている必要があります）。このようなファイルの例については、付属の[`ledger-file.json`]({{target.github_forkurl}}/blob/{{target.github_branch}}/content/_code-samples/rippled-cli/ledger-file.json)を参照してください。 |
|
||||
| `--load` | **廃止予定** デバッグのためのオプションです。ディスク上のレジャーストアーから初期レジャーを読み込むだけです。 |
|
||||
| `--replay` | デバッグのためのオプションです。`--ledger`と組み合わせて使用し、レジャーの閉鎖をリプレイします。サーバーのレジャーストアーには、当該レジャーとその直前のバージョンのレジャーがすでに格納されている必要があります。サーバーでは、前のレジャーをベースとして使用して、指定されたレジャーのすべてのトランザクションが処理されます。その結果、指定されたレジャーが再作成されます。デバッガーを使用して、特定のトランザクションの処理ロジックを分析するためのブレークポイントを追加できます。 |
|
||||
| `--start` | デバッグのためのオプションです。既知のすべてのAmendment（反対票を投じるようにサーバーに設定されているAmendmentを除く）が適用されている新しいジェネシスレジャーを使用して開始します。したがってこれらのAmendmentの機能は、2週間の[Amendmentプロセス](amendments.html)期間ではなく、2番目のレジャーの開始時から使用可能になります。 |
|
||||
| `--valid` | **廃止予定** デバッグのためのオプションです。ネットワークとの完全同期の前であっても、初期レジャーを有効なネットワークレジャーと見なします。 |
|
||||
|
||||
## クライアントモードのオプション
|
||||
|
||||
```bash
|
||||
rippled [OPTIONS] -- {COMMAND} {COMMAND_PARAMETERS}
|
||||
```
|
||||
|
||||
クライアントモードでは、`rippled`実行可能ファイルが別の`rippled`サービスのクライアントとして動作します。（サービスは別のプロセスでローカルに実行されている同じ実行可能ファイルである場合や、別のサーバー上の`rippled`サーバーである場合があります。）
|
||||
|
||||
クライアントモードで実行するには、いずれかの[`rippled` API](rippled-api.html)メソッドの[コマンドライン構文](request-formatting.html#コマンドライン形式)を指定します。
|
||||
|
||||
クライアントモードは、個別のコマンド構文の他に、[汎用オプション](#汎用オプション)と以下のオプションに対応します。
|
||||
|
||||
| オプション | 説明 |
|
||||
|:------------------------|:---------------------------------------------------|
|
||||
| `--rpc` | サーバーをクライアントモードで実行することを明示的に指定します。必須ではありません。 |
|
||||
| `--rpc_ip {IP_ADDRESS}` | 指定されたIPアドレスの`rippled`サーバーに接続します。オプションでポート番号も指定します。 |
|
||||
| `--rpc_port {PORT}` | **廃止予定** 指定されたポートで`rippled`サーバーに接続します。代わりに、`--rpc_ip`を使用してIPアドレスとともにポートを指定します。 |
|
||||
|
||||
**ヒント:** 一部の引数では、マイナスの値を指定できます。APIコマンドの引数がオプションとして解釈されないようにするには、コマンド名の前に`--`引数を渡します。
|
||||
|
||||
使用例（使用可能な最も古いレジャーバージョンから最新のレジャーバージョンまでのアカウントトランザクション履歴を取得）:
|
||||
|
||||
```bash
|
||||
rippled -- account_tx r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59 -1 -1
|
||||
```
|
||||
|
||||
|
||||
## 単体テスト
|
||||
|
||||
```bash
|
||||
rippled --unittest [OPTIONS]
|
||||
rippled -u [OPTIONS]
|
||||
```
|
||||
|
||||
単体テストでは、`rippled`ソースコードに組み込まれているテストを実行し、実行可能ファイルが予期されているとおりに動作することを確認します。単体テストの実行が完了すると、結果の概要が表示され、終了します。単体テストでは、組み込みのデータ型やトランザクション処理ルーチンなどの機能がカバーされます。
|
||||
|
||||
単体テストから失敗が報告される場合、一般的に次のいずれかの状況が発生しています。
|
||||
|
||||
- `rippled`のコンパイル時に問題が発生し、意図したとおりに機能していない
|
||||
- `rippled`のソースコードにバグがある
|
||||
- 単体テストにバグがあるか、単体テストが新しい動作に対応して更新されていない
|
||||
|
||||
単体テストの実行時には、[汎用オプション](#汎用オプション)と以下のいずれかのオプションを指定できます。
|
||||
|
||||
| オプション | 短縮形 | 説明 |
|
||||
|:-----------------------------------|:--------------|:------------------------|
|
||||
| `--unittest-ipv6` | | 単体テストの実行時に[IPv6](https://en.wikipedia.org/wiki/IPv6)を使用してローカルサーバーに接続します。このオプションが指定されていない場合、単体テストではIPv4が代わりに使用されます。[新規: rippled 1.1.0][] |
|
||||
| `--unittest-jobs {NUMBER_OF_JOBS}` | | 指定された数のプロセスを使用して単体テストを実行します。これにより、マルチコアシステムの単体テストをより短時間で終了できます。`{NUMBER_OF_JOBS}`には、使用するプロセスの数を示すプラスの整数値を指定します。 |
|
||||
| `--unittest-log` | | `--quiet`が指定されている場合でも、単体テストにてログへの書き込みができるようにします。（それ以外の影響はありません。） |
|
||||
| `--quiet` | `-q` | 単体テストの実行時に出力される診断メッセージの数が減少します。 |
|
||||
|
||||
|
||||
### 特定の単体テスト
|
||||
|
||||
```bash
|
||||
rippled --unittest={TEST_OR_PACKAGE_NAME}
|
||||
```
|
||||
|
||||
デフォルトでは、`rippled`は「手動」に分類されている単体テスト以外のすべての単体テストを実行します。テストの名前を指定してテストを個別に実行するか、またはパッケージ名を指定してテストのサブセットを実行することができます。
|
||||
|
||||
テストはパッケージの階層にまとめられます。パッケージは`.`文字で区切られ、テストケース名で終わります。
|
||||
|
||||
#### 単体テストの出力
|
||||
|
||||
```bash
|
||||
rippled --unittest=print
|
||||
```
|
||||
|
||||
`print`は、使用可能なテストとそのパッケージのリストを出力する特殊な単体テストです。
|
||||
|
||||
#### 手動単体テスト
|
||||
|
||||
完了に時間を要する一部の単体テストは、「手動」に分類されています。このようなテストについては、`print`単体テストの出力に`|M|`と表示されます。すべての単体テストまたは単体テストのパッケージを実行するときには、手動テストはデフォルトで実行されません。手動テストを個別に実行するには、テスト名を指定します。例:
|
||||
|
||||
```bash
|
||||
$ ./rippled --unittest=ripple.tx.OversizeMeta
|
||||
ripple.tx.OversizeMeta
|
||||
Longest suite times:
|
||||
60.9s ripple.tx.OversizeMeta
|
||||
60.9s, 1 suite, 1 case, 9016 tests total, 0 failures
|
||||
```
|
||||
|
||||
#### 単体テストの引数の指定
|
||||
|
||||
特定の手動単体テストでは引数を指定できます。以下のオプションを使用して引数を指定します。
|
||||
|
||||
| オプション | 説明 |
|
||||
|:------------------------|:---------------------------------------------------|
|
||||
| `--unittest-arg {ARG}` | 実行される単体テストに引数`{ARG}`を指定します。引数を受け入れる単体テストはそれぞれ、固有の引数形式を定義しています。 |
|
||||
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -0,0 +1,40 @@
|
||||
# レジャーヘッダー
|
||||
[[ソース]<br>](https://github.com/ripple/rippled/blob/master/src/ripple/ledger/ReadView.h#L71 "Source")
|
||||
|
||||
すべてのレジャーバージョンには、その内容を記述する一意のヘッダーが含まれています。[ledgerメソッド][]を使用してレジャーのヘッダー情報を検索できます。レジャーヘッダーの内容を以下に示します。
|
||||
|
||||
| フィールド | JSONの型 | [内部の型][] | 説明 |
|
||||
|:-------------------------------|:----------|:------------------|:------------|
|
||||
| [`ledger_index`][レジャーインデックス] | 文字列 | UInt32 | このレジャーのシーケンス番号。APIメソッドの中には、この番号を引用符で囲んだ整数として表示するメソッドと、ネイティブJSON数値として表示するメソッドがあります。 |
|
||||
| `ledger_hash` | 文字列 | Hash256 | このレジャーバージョンの[SHA-512ハーフ][]。これは、このレジャーとそのすべての内容の一意のIDとして機能します。 |
|
||||
| `account_hash` | 文字列 | Hash256 | このレジャーの状態ツリー情報の[SHA-512ハーフ][]。 |
|
||||
| `close_time` | 数値 | UInt32 | このレジャーが閉鎖されたおおよその時刻。Rippleエポック（2000-01-01 00:00:00）以降の経過秒数として示されます。この値は`close_time_resolution`に基づいて丸められるので、これ以降のレジャーに同じ値が含まれることがあります。 |
|
||||
| `closed` | ブール値 | bool | trueの場合、このレジャーバージョンはこれ以上新しいトランザクションを受け入れません。（ただし、このレジャーバージョンが未検証の場合は、一連の異なるトランザクションが記録されている別のレジャーバージョンに置き換えられることがあります。） |
|
||||
| `parent_hash` | 文字列 | Hash256 | このレジャーを作成するために使用された直前のレジャーの`ledger_hash`値。直前のレジャーインデックスの異なるバージョンが存在している場合、これはレジャーの生成元を示します。 |
|
||||
| `total_coins` | 文字列 | UInt64 | レジャーのアカウントが保有する[XRPのdrop数][XRP、drop単位]の合計。トランザクション手数料により消却されたXRPは除外されます。一部のアカウントは、そのキーを知っている人がいない「ブラックホール」アカウントであるため、流通している実際のXRPの量はこれよりも少なくなります。 |
|
||||
| `transaction_hash` | 文字列 | Hash256 | このレジャーに記録されているトランザクションの[SHA-512ハーフ][]。 |
|
||||
| `close_time_resolution` | 数値 | Uint8 | `close_time`を丸めるときの最大秒数を示す範囲 \[2,120\] 内の整数。 |
|
||||
| [`closeFlags`](#closeフラグ) | （省略） | UInt8 | このレジャーの閉鎖に関連するフラグのビットマップ。 |
|
||||
|
||||
|
||||
## レジャーインデックス
|
||||
{% include '_snippets/data_types/ledger_index.md' %}
|
||||
<!--{#_ #}-->
|
||||
|
||||
|
||||
## closeフラグ
|
||||
|
||||
レジャーでは1つのフラグだけがcloseFlagsとして設定されています（**sLCF_NoConsensusTime**（値`1`））。このフラグが有効な場合、バリデータによってレジャーの閉鎖時刻が異なります。ただし、作成しているレジャーは同一のものであるため、バリデータは閉鎖時刻について「合意をしないことに合意する」とした上でコンセンサスを宣言しました。この場合、コンセンサスレジャーバージョンの`close_time`の値は直前のバージョンの1秒後です。（この場合、正式な閉鎖時刻がありませんが、実際の閉鎖時刻はおそらく指定されている`close_time`の3～6秒後です。）
|
||||
|
||||
`closeFlags`フィールドはレジャーのJSON表現には含まれていませんが、レジャーのバイナリ表現には含まれており、レジャーのハッシュを判別するフィールドの1つです。
|
||||
|
||||
|
||||
## 関連項目
|
||||
|
||||
レジャーの基本的な説明については、[レジャー](ledgers.html)を参照してください。
|
||||
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -0,0 +1,18 @@
|
||||
# レジャーオブジェクトID
|
||||
<a id="sha512half"></a>
|
||||
|
||||
レジャーの状態ツリーのすべてのオブジェクトには一意のIDがあります。このフィールドは、オブジェクトの内容と同じレベルでJSONの`index`フィールドとして返されます。IDは、オブジェクトの重要な内容をハッシュし、[名前空間ID](https://github.com/ripple/rippled/blob/master/src/ripple/protocol/LedgerFormats.h#L99)を使用して生成されます。[レジャーオブジェクトタイプ](ledger-object-types.html)により、使用する名前空間IDとハッシュに含める内容が決定します。これにより、すべてのIDが一意になります。ハッシュを計算するため、`rippled`はSHA-512を使用し、その結果を最初の256バイトで切り捨てます。**SHA-512Half**と呼ばれるこのアルゴリズム出力は、SHA-256と同等のセキュリティで、64ビットプロセッサーでは実行にかかる時間が短くなります。
|
||||
|
||||
|
||||
|
||||
|
||||
## 関連項目
|
||||
|
||||
- XRP Ledgerでは、ハッシュがどのように生成、使用されているかについての詳細は、[ハッシュ](basic-data-types.html#ハッシュ)を参照してください。
|
||||
- レジャーの基本的な説明については、[レジャー](ledgers.html)を参照してください。
|
||||
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -0,0 +1,79 @@
|
||||
# AccountRoot
|
||||
[[ソース]<br>](https://github.com/ripple/rippled/blob/5d2d88209f1732a0f8d592012094e345cbe3e675/src/ripple/protocol/impl/LedgerFormats.cpp#L27 "Source")
|
||||
|
||||
`AccountRoot`オブジェクトタイプは、1つの[アカウント](accounts.html)、そのアカウントの設定、XRP残高を記述します。
|
||||
|
||||
## {{currentpage.name}} JSONの例
|
||||
|
||||
```json
|
||||
{
|
||||
"Account": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
|
||||
"AccountTxnID": "0D5FB50FA65C9FE1538FD7E398FFFE9D1908DFA4576D8D7A020040686F93C77D",
|
||||
"Balance": "148446663",
|
||||
"Domain": "6D64756F31332E636F6D",
|
||||
"EmailHash": "98B4375E1D753E5B91627516F6D70977",
|
||||
"Flags": 8388608,
|
||||
"LedgerEntryType": "AccountRoot",
|
||||
"MessageKey": "0000000000000000000000070000000300",
|
||||
"OwnerCount": 3,
|
||||
"PreviousTxnID": "0D5FB50FA65C9FE1538FD7E398FFFE9D1908DFA4576D8D7A020040686F93C77D",
|
||||
"PreviousTxnLgrSeq": 14091160,
|
||||
"Sequence": 336,
|
||||
"TransferRate": 1004999999,
|
||||
"index": "13F1A95D7AAB7108D5CE7EEAF504B2894B8C674E6D68499076441C4837282BF8"
|
||||
}
|
||||
```
|
||||
|
||||
## {{currentpage.name}}フィールド
|
||||
|
||||
`AccountRoot`オブジェクトのフィールドは次のとおりです。
|
||||
|
||||
| フィールド | JSONの型 | [内部の型][] | 説明 |
|
||||
|:------------------------------|:----------|:------------------|:-------------|
|
||||
| `LedgerEntryType` | 文字列 | UInt16 | 値`0x0061`が文字列`AccountRoot`にマッピングされている場合は、これがAccountRootオブジェクトであることを示します。 |
|
||||
| `Account` | 文字列 | AccountID | このアカウントの識別用アドレス（rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpnなど）。 |
|
||||
| `Balance` | 文字列 | Amount | アカウントの現在の[drop単位のXRP残高][XRP、drop単位]で、文字列で表現されます。 |
|
||||
| [`Flags`](#accountrootのフラグ) | 数値 | UInt32 | このアカウントに対して有効になっているブールフラグのビットマップ。 |
|
||||
| `OwnerCount` | 数値 | UInt32 | レジャーでこのアカウントが所有しており、アカウント所有者の準備金に資金を付与するオブジェクトの数。 |
|
||||
| `PreviousTxnID` | 文字列 | Hash256 | 最後にこのオブジェクトを変更したトランザクションの識別用ハッシュ。 |
|
||||
| `PreviousTxnLgrSeq` | 数値 | UInt32 | 最後にこのオブジェクトを変更したトランザクションが記録された[レジャーインデックス][]。 |
|
||||
| `Sequence` | 数値 | UInt32 | このアカウントの次に有効なトランザクションのシーケンス番号。（各アカウントはSequence = 1で開始し、トランザクションが作られるたびにこの値が増加します。） |
|
||||
| `AccountTxnID` | 文字列 | Hash256 | _（省略可）_ このアカウントが最後に送信したトランザクションの識別用ハッシュ。 |
|
||||
| `Domain` | 文字列 | VariableLength | _（省略可）_ このアカウントに関連付けられているドメイン。JSONではこれはドメインのASCII表現の16進数値です。 |
|
||||
| `EmailHash` | 文字列 | Hash128 | _（省略可）_ メールアドレスのmd5ハッシュ。クライアントはこれを使用してサービス内で[Gravatar](https://en.gravatar.com/)などのアバターを検索できます。 |
|
||||
| `MessageKey` | 文字列 | VariableLength | _（省略可）_ 暗号化メッセージをこのアカウントに送信するときに使用できる公開鍵。JSONでは16進数値を使用します。33バイト以下です。 |
|
||||
| `RegularKey` | 文字列 | AccountID | _（省略可）_ このアカウントのトランザクションに署名するときにマスターキーの代わりに使用できるキーペアのアドレス。この値を変更するには[SetRegularKeyトランザクション][]を使用してください。 |
|
||||
| `TickSize` | 数値 | UInt8 | _（省略可）_ このアドレスが発行した通貨が関わるオファーの為替レートに使用する有効桁数。有効な値は`3`以上`15`以下です。_（[TickSize Amendment][]が必要です。）_ |
|
||||
| `TransferRate` | 数値 | UInt32 | _（省略可）_ このアカウントが発行した通貨を他のユーザーが相互に送金する際に、これらのユーザーに請求する[送金手数料](https://ripple.com/knowledge_center/transfer-fees/)。 |
|
||||
| `WalletLocator` | 文字列 | Hash256 | _（省略可）_ **廃止予定**。使用しないでください。 |
|
||||
| `WalletSize` | 数値 | UInt32 | _（省略可）_ **廃止予定**。使用しないでください。 |
|
||||
|
||||
## AccountRootのフラグ
|
||||
|
||||
このアカウントに対して有効化または無効化できる各種オプションがあります。これらのオプションを変更するには、[AccountSetトランザクション][]を使用します。レジャーではフラグはバイナリ値として表され、これらのバイナリ値はビットOR演算と組み合わせることができます。レジャーでのフラグのビット値は、トランザクションでこれらのフラグを有効または無効にするために使用する値とは異なります。レジャーのフラグには、 _lsf_ で始まる名前が付いています。
|
||||
|
||||
AccountRootオブジェクトには以下のフラグ値を指定できます。
|
||||
|
||||
| フラグ名 | 16進数値 | 10進数値 | 説明 | 対応する[AccountSetのフラグ](accountset.html#accountsetのフラグ) |
|
||||
|-----------|-----------|---------------|-------------|-------------------------------|
|
||||
| lsfDefaultRipple | 0x00800000 | 8388608 | このアドレスのトラストラインでデフォルトで[rippling](rippling.html)を有効にします。発行アドレスに必要です。他のアドレスでの使用は推奨されません。 | asfDefaultRipple |
|
||||
| lsfDepositAuth | 0x01000000 | 16777216 | このアカウントは、アカウントが送信するトランザクションと、[事前承認された](depositauth.html#事前承認)アカウントからの資金だけを受領します。（[DepositAuth](depositauth.html)が有効になっています。） | asfDepositAuth |
|
||||
| lsfDisableMaster | 0x00100000 | 1048576 | このアカウントのトランザクションの署名にマスターキーを使用することを禁止します。 | asfDisableMaster |
|
||||
| lsfDisallowXRP | 0x00080000 | 524288 | クライアントアプリケーションはこのアカウントにXRPを送金しないでください。`rippled`により強制されるものではありません。 | asfDisallowXRP |
|
||||
| lsfGlobalFreeze | 0x00400000 | 4194304 | このアドレスが発行するすべての資産が凍結されます。 | asfGlobalFreeze |
|
||||
| lsfNoFreeze | 0x00200000 | 2097152 | このアドレスは、このアドレスに接続しているトラストラインを凍結できません。一度有効にすると、無効にできません。 | asfNoFreeze |
|
||||
| lsfPasswordSpent | 0x00010000 | 65536 | このアカウントは無料のSetRegularKeyトランザクションを使用しています。 | （なし） |
|
||||
| lsfRequireAuth | 0x00040000 | 262144 | このアカウントは、他のユーザーがこのアカウントのイシュアンスを保有することを個別に承認する必要があります。 | asfRequireAuth |
|
||||
| lsfRequireDestTag | 0x00020000 | 131072 | 受信ペイメントには宛先タグの指定が必要です。 | asfRequireDest |
|
||||
|
||||
## AccountRoot IDのフォーマット
|
||||
|
||||
AccountRootオブジェクトのIDは、以下の値がこの順序で連結されている[SHA-512ハーフ][]です。
|
||||
|
||||
* Accountスペースキー（`0x0061`）
|
||||
* アカウントのAccountID
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user