mirror of
https://github.com/XRPLF/xrpl-dev-portal.git
synced 2025-11-19 19:25:51 +00:00
Merge branch 'master' of https://github.com/JakeatRipple/xrpl-dev-portal into feat-use-cases
# Conflicts: # assets/css/devportal2022-v13.css
This commit is contained in:
Jake
@@ -65,6 +65,27 @@ dactyl_link_checker
|
||||
dactyl_style_checker
|
||||
```
|
||||
|
||||
### 日本語サイトのビルド
|
||||
|
||||
ターゲットと出力先を指定してビルドしてください。
|
||||
|
||||
```
|
||||
dactyl_build -t ja -o out/ja
|
||||
```
|
||||
|
||||
日本語サイトの場合、生成されたコンテンツをウェブブラウザーでファイルとして開くことができません。ローカルHTTPサーバーやエディターの拡張機能(VSCodeであればLive Serverなど)を利用してください。
|
||||
|
||||
##### ローカルでHTTPサーバを利用する方法
|
||||
|
||||
1. `out`直下で次のコマンドを実施しサーバーを起動する
|
||||
|
||||
```
|
||||
python -m http.server
|
||||
```
|
||||
|
||||
2. ウェブブラウザーから`localhost`にアクセスする。
|
||||
サーバー起動時にアサインされたポート番号を利用してください。
|
||||
|
||||
## 設定の書式
|
||||
|
||||
このリポジトリー内のテンプレートは`dactyl-config.yml`ファイルのメタデータを使用して、生成されたサイトをナビゲートする際のページ階層を生成します。ナビゲーションを正しく生成するには、ページの定義に適切なフィールドを含める必要があります。以下の例に、すべてのフィールドを指定したページを示します。
|
||||
|
||||
2
LICENSE
2
LICENSE
@@ -2,7 +2,7 @@ The XRP Ledger Dev Portal (XRPL.org) and all its original contents are provided
|
||||
|
||||
The MIT License (MIT)
|
||||
|
||||
XRP Ledger Dev Portal Copyright (c) 2021 XRP Ledger Foundation and contributors, https://xrplf.org/
|
||||
XRP Ledger Dev Portal Copyright (c) 2023 XRP Ledger Foundation and contributors, https://xrplf.org/
|
||||
jQuery Copyright (c) 2005, 2014 jQuery Foundation and other contributors, https://jquery.org/
|
||||
Bootstrap Copyright (c) 2011-2019 Twitter, Inc.
|
||||
Bootstrap Copyright (c) 2011-2019 The Bootstrap Authors
|
||||
|
||||
File diff suppressed because one or more lines are too long
178
assets/js/xrp-ledger-toml-checker-test.js
Normal file
178
assets/js/xrp-ledger-toml-checker-test.js
Normal file
@@ -0,0 +1,178 @@
|
||||
// This code takes in a wallet address, checks the domain field, then gets the TOML info to verify the domains ownership.
|
||||
// This is runnable in NODE JS for easier testing, and works the same as the code in xrp-ledger-toml-checker.js
|
||||
const WebSocket = require('ws');
|
||||
const https = require('https');
|
||||
const TOML = require('../vendor/iarna-toml-parse');
|
||||
|
||||
const TOML_PATH = "/.well-known/xrp-ledger.toml"
|
||||
|
||||
const ACCOUNT_FIELDS = [
|
||||
"address",
|
||||
"network",
|
||||
"desc"
|
||||
]
|
||||
|
||||
// Test wallet addresses
|
||||
const WORKS = 'rSTAYKxF2K77ZLZ8GoAwTqPGaphAqMyXV'
|
||||
const NOTOML = 'rsoLo2S1kiGeCcn6hCUXVrCpGMWLrRrLZz'
|
||||
const NODOMAIN = 'rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh'
|
||||
|
||||
let socket;
|
||||
|
||||
function makeLogEntry(text) {
|
||||
log = console.log(text + '\n')
|
||||
}
|
||||
|
||||
function fetchFile(domain) {
|
||||
const url = "https://" + domain + TOML_PATH
|
||||
makeLogEntry('CHECKING DOMAIN: ' + url)
|
||||
https.get(url, (resp) => {
|
||||
let data = '';
|
||||
resp.on('data', (chunk) => {
|
||||
data += chunk;
|
||||
});
|
||||
resp.on('end', () => {
|
||||
if (data != '') {
|
||||
makeLogEntry('TOML FILE: Found');
|
||||
parseXrplToml(data)
|
||||
} else {
|
||||
makeLogEntry('TOML FILE: Not found')
|
||||
makeLogEntry('ACCOUNT CAN NOT BE VERIFIED: TOML file was not found.')
|
||||
return
|
||||
}
|
||||
});
|
||||
}).on("error", (err) => {
|
||||
if (err.code == 'ENOTFOUND') {
|
||||
makeLogEntry('ACCOUNT CAN NOT BE VERIFIED: Network error while fetching TOML file.')
|
||||
}
|
||||
return
|
||||
});
|
||||
}
|
||||
|
||||
function fetchWallet() {
|
||||
makeLogEntry('\nCHECKING DOMAIN OF ACCOUNT...')
|
||||
const url = "wss://xrplcluster.com"
|
||||
if (typeof socket !== "undefined" && socket.readyState < 2) {
|
||||
socket.close()
|
||||
}
|
||||
const data = {
|
||||
"command": "account_info",
|
||||
"account": wallet,
|
||||
}
|
||||
socket = new WebSocket(url)
|
||||
socket.addEventListener('message', (event) => {
|
||||
let data;
|
||||
try {
|
||||
data = JSON.parse(event.data)
|
||||
if (data.status === 'success') {
|
||||
if (data.result.account_data.Domain) {
|
||||
try {
|
||||
makeLogEntry('ACCOUNT ADDRESS: Valid')
|
||||
decodeHex(data.result.account_data.Domain)
|
||||
} catch {
|
||||
makeLogEntry('error decoding domain field: ' + data.result.account_data.Domain)
|
||||
}
|
||||
} else {
|
||||
makeLogEntry('ACCOUNT ADDRESS: Valid')
|
||||
makeLogEntry('DOMAIN DECODED: Domain field not found')
|
||||
makeLogEntry('CHECKING DOMAIN: Error')
|
||||
makeLogEntry('TOML FILE: Not found')
|
||||
makeLogEntry('ACCOUNT CAN NOT BE VERIFIED: Account has no domain field.')
|
||||
return
|
||||
}
|
||||
} else {
|
||||
makeLogEntry('ACCOUNT ADDRESS: Invalid')
|
||||
makeLogEntry('DOMAIN DECODED: Domain field not found')
|
||||
makeLogEntry('CHECKING DOMAIN: Error')
|
||||
makeLogEntry('TOML FILE: Not found')
|
||||
makeLogEntry('ACCOUNT CAN NOT BE VERIFIED: Account address is not valid.')
|
||||
return
|
||||
}
|
||||
} catch (e) {
|
||||
makeLogEntry(e)
|
||||
return
|
||||
}
|
||||
})
|
||||
socket.addEventListener('open', () => {
|
||||
socket.send(JSON.stringify(data))
|
||||
})
|
||||
}
|
||||
|
||||
async function parseXrplToml(data) {
|
||||
let parsed
|
||||
makeLogEntry("Parsing TOML data...")
|
||||
try {
|
||||
parsed = TOML(data)
|
||||
} catch (e) {
|
||||
makeLogEntry('ACCOUNT CAN NOT BE VERIFIED: TOML file can not be read.')
|
||||
return
|
||||
}
|
||||
|
||||
async function listEntries(list, fields) {
|
||||
makeLogEntry('\nADDRESSES:')
|
||||
let found = false;
|
||||
for (i = 0; i < list.length; i++) {
|
||||
let entry = list[i]
|
||||
for (j = 0; j < fields.length; j++) {
|
||||
let fieldname = fields[j]
|
||||
if (fieldname == 'address' && entry[fieldname] !== undefined) {
|
||||
if (entry[fieldname] === wallet) {
|
||||
makeLogEntry('MATCH: ' + entry[fieldname] + ' *')
|
||||
found = true;
|
||||
} else {
|
||||
makeLogEntry('NO_MATCH: ' + entry[fieldname])
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
if (found) {
|
||||
makeLogEntry('ACCOUNT IS PRESENT: Account domain verified')
|
||||
} else {
|
||||
makeLogEntry('ACCOUNT IS NOT PRESENT: Account domain can not be verified')
|
||||
}
|
||||
return
|
||||
}
|
||||
if (parsed.ACCOUNTS) {
|
||||
if (!Array.isArray(parsed.ACCOUNTS)) {
|
||||
makeLogEntry("Wrong type- should be table-array")
|
||||
process.exit()
|
||||
} else {
|
||||
listEntries(parsed.ACCOUNTS, ACCOUNT_FIELDS)
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
function decodeHex(hex) {
|
||||
let str = '';
|
||||
for (let i = 0; i < hex.length; i += 2) {
|
||||
str += String.fromCharCode(parseInt(hex.substr(i, 2), 16))
|
||||
}
|
||||
makeLogEntry('DOMAIN DECODED: ' + str)
|
||||
fetchFile(str)
|
||||
}
|
||||
|
||||
// 'wallet' must be a global func.
|
||||
let wallet;
|
||||
|
||||
function main() {
|
||||
makeLogEntry('\n\n--------EXAMPLE OF FAIL: WEBSITE TOML ERROR--------')
|
||||
wallet = NOTOML
|
||||
fetchWallet()
|
||||
|
||||
setTimeout(function() {
|
||||
makeLogEntry('\n\n--------EXAMPLE OF FAIL: NO DOMAIN FIELD--------')
|
||||
wallet = NODOMAIN
|
||||
fetchWallet()
|
||||
|
||||
setTimeout(function() {
|
||||
makeLogEntry('\n\n--------EXAMPLE OF SUCCESS--------')
|
||||
wallet = WORKS
|
||||
fetchWallet()
|
||||
|
||||
setTimeout(function(){process.exit()},5000)
|
||||
}, 5000)
|
||||
}, 5000)
|
||||
|
||||
}
|
||||
|
||||
main()
|
||||
@@ -1,5 +1,7 @@
|
||||
const TOML_PATH = "/.well-known/xrp-ledger.toml"
|
||||
const TIPS = '<p>Check if the file is actually hosted at the URL above, check your server\'s HTTPS settings and certificate, and make sure your server provides the required <a href="xrp-ledger-toml.html#cors-setup">CORS header.</a></p>'
|
||||
const TIPS_1 = '<p>Make sure you are entering a valid XRP Ledger address.</p>'
|
||||
const TIPS_2 = '<p>Make sure the account has the Domain field set.</p>'
|
||||
const CLASS_GOOD = "badge badge-success"
|
||||
const CLASS_BAD = "badge badge-danger"
|
||||
|
||||
@@ -53,17 +55,28 @@ function makeLogEntry(text, raw) {
|
||||
return log
|
||||
}
|
||||
|
||||
function fetch_file() {
|
||||
function fetchFile(walletDomain) {
|
||||
var url;
|
||||
var log;
|
||||
const domain = $('#domain').val()
|
||||
const url = "https://" + domain + TOML_PATH
|
||||
if (walletDomain !== undefined) {
|
||||
url = "https://" + walletDomain + TOML_PATH
|
||||
log = makeLogEntryWallet('Checking ' + url + '...')
|
||||
} else {
|
||||
url = "https://" + domain + TOML_PATH
|
||||
log = makeLogEntry('Checking ' + url + '...')
|
||||
}
|
||||
|
||||
const log = makeLogEntry('Checking ' + url + '...')
|
||||
$.ajax({
|
||||
url: url,
|
||||
dataType: 'text',
|
||||
success: function(data) {
|
||||
log.resolve('FOUND').addClass(CLASS_GOOD)
|
||||
parse_xrpl_toml(data, domain)
|
||||
if (typeof walletDomain !== 'undefined'){
|
||||
parseXRPLTomlWallet(data)
|
||||
} else{
|
||||
parseXRPLToml(data, domain)
|
||||
}
|
||||
},
|
||||
error: function(jqxhr, status, error) {
|
||||
switch (status) {
|
||||
@@ -84,19 +97,17 @@ function fetch_file() {
|
||||
})
|
||||
}
|
||||
|
||||
async function parse_xrpl_toml(data, domain) {
|
||||
async function parseXRPLToml(data, domain) {
|
||||
let parsed
|
||||
let log1 = makeLogEntry("Parsing TOML data...")
|
||||
let logTOML = makeLogEntry("Parsing TOML data...")
|
||||
try {
|
||||
parsed = TOML(data)
|
||||
log1.resolve("SUCCESS").addClass(CLASS_GOOD)
|
||||
logTOML.resolve("SUCCESS").addClass(CLASS_GOOD)
|
||||
} catch(e) {
|
||||
log1.resolve(e).addClass(CLASS_BAD)
|
||||
logTOML.resolve(e).addClass(CLASS_BAD)
|
||||
return
|
||||
}
|
||||
|
||||
console.log(parsed)
|
||||
|
||||
if (parsed.hasOwnProperty("METADATA")) {
|
||||
const metadata_type = makeLogEntry("Metadata section: ")
|
||||
if (Array.isArray(parsed.METADATA)) {
|
||||
@@ -115,7 +126,7 @@ async function parse_xrpl_toml(data, domain) {
|
||||
}
|
||||
}
|
||||
|
||||
async function list_entries(name, list, fields, validate) {
|
||||
async function listEntries(name, list, fields, validate) {
|
||||
let list_wrap = $("<p>"+name+"</p>")
|
||||
let list_ol = $("<ol>").appendTo(list_wrap)
|
||||
for (i=0; i<list.length; i++) {
|
||||
@@ -144,11 +155,11 @@ async function parse_xrpl_toml(data, domain) {
|
||||
if (!Array.isArray(parsed.ACCOUNTS)) {
|
||||
makeLogEntry("Accounts:").resolve("Wrong type - should be table-array").addClass(CLASS_BAD)
|
||||
} else {
|
||||
list_entries("Accounts:", parsed.ACCOUNTS, ACCOUNT_FIELDS, async function(acct) {
|
||||
listEntries("Accounts:", parsed.ACCOUNTS, ACCOUNT_FIELDS, async function(acct) {
|
||||
if (acct.address === undefined) {return undefined}
|
||||
let net
|
||||
if (acct.network === undefined) { net = "main" } else { net = acct.network }
|
||||
return await validate_address_domain_on_net(acct.address, domain, net)
|
||||
return await validateAddressDomainOnNet(acct.address, domain, net)
|
||||
})
|
||||
}
|
||||
}
|
||||
@@ -156,28 +167,28 @@ async function parse_xrpl_toml(data, domain) {
|
||||
if (!Array.isArray(parsed.VALIDATORS)) {
|
||||
makeLogEntry("Validators:").resolve("Wrong type - should be table-array").addClass(CLASS_BAD)
|
||||
} else {
|
||||
list_entries("Validators:", parsed.VALIDATORS, VALIDATOR_FIELDS)
|
||||
listEntries("Validators:", parsed.VALIDATORS, VALIDATOR_FIELDS)
|
||||
}
|
||||
}
|
||||
if (parsed.PRINCIPALS) {
|
||||
if (!Array.isArray(parsed.PRINCIPALS)) {
|
||||
makeLogEntry("Principals:").resolve("Wrong type - should be table-array").addClass(CLASS_BAD)
|
||||
} else {
|
||||
list_entries("Principals:", parsed.PRINCIPALS, PRINCIPAL_FIELDS)
|
||||
listEntries("Principals:", parsed.PRINCIPALS, PRINCIPAL_FIELDS)
|
||||
}
|
||||
}
|
||||
if (parsed.SERVERS) {
|
||||
if (!Array.isArray(parsed.SERVERS)) {
|
||||
makeLogEntry("Servers:").resolve("Wrong type - should be table-array").addClass(CLASS_BAD)
|
||||
} else {
|
||||
list_entries("Servers:", parsed.SERVERS, SERVER_FIELDS)
|
||||
listEntries("Servers:", parsed.SERVERS, SERVER_FIELDS)
|
||||
}
|
||||
}
|
||||
if (parsed.CURRENCIES) {
|
||||
if (!Array.isArray(parsed.CURRENCIES)) {
|
||||
makeLogEntry("Currencies:").resolve("Wrong type - should be table-array").addClass(CLASS_BAD)
|
||||
} else {
|
||||
list_entries("Currencies:", parsed.CURRENCIES, CURRENCY_FIELDS)
|
||||
listEntries("Currencies:", parsed.CURRENCIES, CURRENCY_FIELDS)
|
||||
}
|
||||
}
|
||||
}
|
||||
@@ -185,7 +196,7 @@ async function parse_xrpl_toml(data, domain) {
|
||||
// Decode a hexadecimal string into a regular string, assuming 8-bit characters.
|
||||
// Not proper unicode decoding, but it'll work for domains which are supposed
|
||||
// to be a subset of ASCII anyway.
|
||||
function decode_hex(hex) {
|
||||
function decodeHex(hex) {
|
||||
let str = '';
|
||||
for (let i = 0; i < hex.length; i += 2) {
|
||||
str += String.fromCharCode(parseInt(hex.substr(i, 2), 16))
|
||||
@@ -193,7 +204,7 @@ function decode_hex(hex) {
|
||||
return str
|
||||
}
|
||||
|
||||
async function validate_address_domain_on_net(address, domain, net) {
|
||||
async function validateAddressDomainOnNet(address, domain, net) {
|
||||
if (!domain) { return undefined } // Can't validate an empty domain value
|
||||
let api
|
||||
if (net === "main") {
|
||||
@@ -223,7 +234,7 @@ async function validate_address_domain_on_net(address, domain, net) {
|
||||
|
||||
let domain_decoded
|
||||
try {
|
||||
domain_decoded = decode_hex(ai.result.account_data.Domain)
|
||||
domain_decoded = decodeHex(ai.result.account_data.Domain)
|
||||
} catch(e) {
|
||||
console.warn("error decoding domain value", ai.result.account_data.Domain, e)
|
||||
api.disconnect()
|
||||
@@ -244,16 +255,162 @@ async function validate_address_domain_on_net(address, domain, net) {
|
||||
}
|
||||
}
|
||||
|
||||
function handle_submit(event) {
|
||||
function handleSubmitDomain(event) {
|
||||
event.preventDefault();
|
||||
|
||||
$('.result-title').show()
|
||||
$('#result').show()
|
||||
$('#log').empty()
|
||||
|
||||
fetch_file()
|
||||
fetchFile()
|
||||
}
|
||||
|
||||
// ------------------------------------------ DOMAIN VERIFICATION VIA ACCOUNT BELOW ------------------------------------------
|
||||
let wallet;
|
||||
let socket;
|
||||
|
||||
function makeLogEntryWallet(text, raw) {
|
||||
let log
|
||||
if (raw) {
|
||||
log = $('<li></li>').appendTo('#verify-domain-log').append(text)
|
||||
} else {
|
||||
log = $('<li></li>').text(text+" ").appendTo('#verify-domain-log')
|
||||
}
|
||||
log.resolve = function(text) {
|
||||
return $('<span></span>').html(text).appendTo(log)
|
||||
}
|
||||
return log
|
||||
}
|
||||
|
||||
function fetchWallet() {
|
||||
wallet = $('#verify-domain').val()
|
||||
const checkingLog = makeLogEntryWallet('Checking domain of account')
|
||||
const url = "wss://xrplcluster.com"
|
||||
if (typeof socket !== "undefined" && socket.readyState < 2) {
|
||||
socket.close()
|
||||
}
|
||||
const data = {
|
||||
"command": "account_info",
|
||||
"account": wallet,
|
||||
}
|
||||
socket = new WebSocket(url)
|
||||
socket.addEventListener('message', (event) => {
|
||||
let data;
|
||||
try {
|
||||
data = JSON.parse(event.data)
|
||||
if (data.status === 'success') {
|
||||
if (data.result.account_data.Domain) {
|
||||
try {
|
||||
checkingLog.resolve('SUCCESS').addClass(CLASS_GOOD)
|
||||
decodeHexWallet(data.result.account_data.Domain)
|
||||
} catch(e) {
|
||||
console.log(e)
|
||||
checkingLog.resolve('ERROR').addClass(CLASS_BAD).after('<p>Error decoding domain field: ' + data.result.account_data.Domain + '</p>')
|
||||
}
|
||||
} else {
|
||||
checkingLog.resolve('ERROR').addClass(CLASS_BAD).after(TIPS_2)
|
||||
}
|
||||
} else {
|
||||
checkingLog.resolve('ERROR').addClass(CLASS_BAD).after(TIPS_1)
|
||||
}
|
||||
} catch {
|
||||
return false
|
||||
}
|
||||
})
|
||||
socket.addEventListener('open', () => {
|
||||
socket.send(JSON.stringify(data))
|
||||
})
|
||||
}
|
||||
|
||||
async function parseXRPLTomlWallet(data) {
|
||||
let parsed
|
||||
let logTOML = makeLogEntryWallet("Parsing TOML data...")
|
||||
try {
|
||||
parsed = TOML(data)
|
||||
logTOML.resolve("SUCCESS").addClass(CLASS_GOOD)
|
||||
} catch(e) {
|
||||
logTOML.resolve(e).addClass(CLASS_BAD)
|
||||
return
|
||||
}
|
||||
|
||||
if (parsed.hasOwnProperty("METADATA")) {
|
||||
const metadata_type = makeLogEntryWallet("Metadata section: ")
|
||||
if (Array.isArray(parsed.METADATA)) {
|
||||
metadata_type.resolve("Wrong type - should be table").addClass(CLASS_BAD)
|
||||
} else {
|
||||
metadata_type.resolve("Found").addClass(CLASS_GOOD)
|
||||
|
||||
if (parsed.METADATA.modified) {
|
||||
const mod_log = makeLogEntryWallet("Modified date: ")
|
||||
try {
|
||||
mod_log.resolve(parsed.METADATA.modified.toISOString()).addClass(CLASS_GOOD)
|
||||
} catch(e) {
|
||||
mod_log.resolve("INVALID").addClass(CLASS_BAD)
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
async function listEntriesWallet(name, list, fields) {
|
||||
let found = false;
|
||||
let list_wrap = $("<p>"+name+"</p>")
|
||||
let list_ol = $("<ol>").appendTo(list_wrap)
|
||||
for (i=0; i<list.length; i++) {
|
||||
let entry_def = $("<ul>").appendTo(list_ol)
|
||||
let entry = list[i]
|
||||
for (j=0; j<fields.length; j++) {
|
||||
let fieldname = fields[j]
|
||||
if (entry['address'] === wallet) {
|
||||
let field_def = $("<li><strong>"+fieldname+": </strong>").appendTo(entry_def)
|
||||
$(" <span class='"+fieldname+"'>").text(entry[fieldname]).appendTo(field_def)
|
||||
found=true;
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
if(found) {
|
||||
makeLogEntryWallet(list_wrap, true)
|
||||
makeLogEntryWallet('Account has been found in TOML file and validated.').resolve('DOMAIN VALIDATED <i class="fa fa-check-circle"></i>').addClass(CLASS_GOOD)
|
||||
} else {
|
||||
let entry_def = $("<ul>").appendTo(list_ol)
|
||||
let field_def = $("<li><strong>address: </strong>").appendTo(entry_def)
|
||||
$(" <span class='address'>").text('Not found ').appendTo(field_def).append(' <li class="badge badge-danger">ERROR</li>')
|
||||
|
||||
makeLogEntryWallet(list_wrap, true)
|
||||
makeLogEntryWallet('Account not found in TOML file. Domain can not be verified.').resolve('VALIDATION FAILED').addClass(CLASS_BAD)
|
||||
}
|
||||
}
|
||||
if (parsed.ACCOUNTS) {
|
||||
if (!Array.isArray(parsed.ACCOUNTS)) {
|
||||
makeLogEntryWallet("Account:").resolve("Wrong type - should be table-array").addClass(CLASS_BAD)
|
||||
} else {
|
||||
listEntriesWallet("Account:", parsed.ACCOUNTS, ACCOUNT_FIELDS)
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
function decodeHexWallet(hex) {
|
||||
let str = '';
|
||||
for (let i = 0; i < hex.length; i += 2) {
|
||||
str += String.fromCharCode(parseInt(hex.substr(i, 2), 16))
|
||||
}
|
||||
const decodeLog = makeLogEntryWallet('Decoding domain hex')
|
||||
decodeLog.resolve("SUCCESS").addClass(CLASS_GOOD)
|
||||
fetchFile(str)
|
||||
}
|
||||
|
||||
function handleSubmitWallet(event) {
|
||||
event.preventDefault();
|
||||
|
||||
$('#verify-domain-result-title').show()
|
||||
$('#verify-domain-result').show()
|
||||
$('#verify-domain-log').empty()
|
||||
|
||||
fetchWallet()
|
||||
}
|
||||
|
||||
|
||||
$(document).ready(() => {
|
||||
$('#domain-entry').submit(handle_submit)
|
||||
$('#domain-entry').submit(handleSubmitDomain)
|
||||
$('#domain-verification').submit(handleSubmitWallet)
|
||||
})
|
||||
|
||||
@@ -7,246 +7,71 @@ labels:
|
||||
---
|
||||
# Amendments
|
||||
|
||||
[Introduced in: rippled 0.31.0][]
|
||||
The amendment system uses the consensus process to approve any changes that affect transaction processing on the XRP Ledger. Fully-functional, transaction process changes are introduced as amendments; validators then vote on these changes. If an amendment receives more than 80% support for two weeks, the amendment passes and the change applies permanently to all subsequent ledger versions. Disabling a passed amendment requires a new amendment to do so.
|
||||
|
||||
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 **more than 80% support for two weeks** before it can apply.
|
||||
|
||||
When an Amendment has been enabled, it applies permanently to all ledger versions after the one that included it. You cannot disable an Amendment, unless you introduce a new Amendment to do so.
|
||||
|
||||
For a complete list of known amendments, their statuses, and IDs, see: [Known Amendments](known-amendments.html).
|
||||
|
||||
## Background
|
||||
|
||||
Any changes to transaction processing could cause servers to build a different ledger with the same set of transactions. If some _validators_ (`rippled` servers [participating in consensus](rippled-server-modes.html#validators)) have upgraded to a new version of the software while other validators use the old version, this could cause anything from minor inconveniences to full outages. In the minor case, a minority of servers spend more time and bandwidth fetching the actual consensus ledger because they cannot build it using the transaction processing rules they already know. In the worst case, [the consensus process][] might be unable to validate new ledger versions because servers with different rules could not reach a consensus on the exact ledger to build.
|
||||
|
||||
Amendments solve this problem, so that new features can be enabled only when enough validators support those features.
|
||||
|
||||
Users and businesses who rely on the XRP Ledger can also use Amendments to provide advance notice of changes in transaction processing that might affect their business. However, API changes that do not impact transaction processing or [the consensus process][] do not need Amendments.
|
||||
|
||||
[the consensus process]: consensus.html
|
||||
|
||||
|
||||
## About Amendments
|
||||
|
||||
An amendment is a fully-functional feature or change, waiting to be enabled by the peer-to-peer network as a part of the consensus process. A `rippled` server that wants to use an amendment has code for two modes: without the amendment (old behavior) and with the amendment (new behavior).
|
||||
|
||||
Every amendment has a unique identifying hex value and a short name. The short name is for human use, and is not used in the amendment process. Two servers can support the same amendment ID while using different names to describe it. An amendment's name is not guaranteed to be unique.
|
||||
|
||||
By convention, an amendment's ID should be the SHA-512Half hash of the amendment's short name.
|
||||
**Note:** Bug fixes that change transaction processes also require amendments.
|
||||
|
||||
<!-- TODO: Move this to an amendment tutorial.
|
||||
Every amendment has a unique identifying hex value and a short name. The short name is for readability only; servers can use different names to describe the same amendement ID, and the names aren't guaranteed to be unique. The amendment ID should be the SHA-512Half hash of the amendment's short name.
|
||||
-->
|
||||
|
||||
## Amendment Process
|
||||
|
||||
Every 256th ledger is called a "flag" ledger. The process of approving an amendment starts in the ledger version immediately before the flag ledger. When `rippled` validator servers send validation messages for that ledger, those servers also submit votes in favor of specific amendments. If a validator does not vote in favor of an amendment, that is the same as voting against the amendment. However, the `rippled` reference implementation has a default vote for each known amendment, which determines how a validator votes on any amendment for which that validator does not have an explicit configuration. ([Fee Voting](fee-voting.html) also occurs around flag ledgers.) [Updated in: rippled 1.8.1][]
|
||||
Every 256th ledger is called a **flag** ledger. The flag ledger doesn't have special contents, but the amendment process happens around it.
|
||||
|
||||
The flag ledger itself has no special contents. However, during that time, the servers look at the votes of the validators they trust, and decide whether to insert an [`EnableAmendment` pseudo-transaction](enableamendment.html) into the following ledger. The flags of an EnableAmendment pseudo-transaction show what the server thinks happened:
|
||||
1. **Flag Ledger -1:** When `rippled` validators send validation messages, they also submit their amendment votes.
|
||||
2. **Flag Ledger:** Servers interpret the votes from trusted validators.
|
||||
3. **Flag Ledger +1:** Servers insert an `EnableAmendment` pseudo-transaction and flag based on what they think happened:
|
||||
* The `tfGotMajority` flag means the amendment has more than 80% support.
|
||||
* The `tfLostMajority` flag means support for the amendment has decreased to 80% or less.
|
||||
* No flag means the amendment is enabled.
|
||||
|
||||
* The `tfGotMajority` flag means that support for the amendment has increased to more than 80% of trusted validators.
|
||||
* The `tfLostMajority` flag means that support for the amendment has decreased to 80% of trusted validators or less.
|
||||
* An EnableAmendment pseudo-transaction with no flags means that support for the amendment has been enabled. (The change in transaction processing applies to every ledger after this one.)
|
||||
**Note:** It's possible for an amendment to lose 80% support on the same ledger it reaches the required two-week period to be enabled. In these cases, an `EnableAmendment` pseudo-transactions is added for both scenarios, but the amendment is ultimately enabled.
|
||||
|
||||
A server only inserts the pseudo-transaction to enable an amendment if all of the following conditions are met:
|
||||
4. **Flag Ledger +2:** Enabled amendments apply to transactions on this ledger onwards.
|
||||
|
||||
* The amendment has not already been enabled.
|
||||
* A previous ledger includes an EnableAmendment pseudo-transaction for this amendment with the `tfGotMajority` flag enabled.
|
||||
* The previous ledger in question is an ancestor of the current ledger.
|
||||
* The previous ledger in question has a close time that is at least **two weeks** before the close time of the latest flag ledger.
|
||||
* There are no EnableAmendment pseudo-transactions for this amendment with the `tfLostMajority` flag enabled in the consensus ledgers between the `tfGotMajority` pseudo-transaction and the current ledger.
|
||||
|
||||
Theoretically, a `tfLostMajority` EnableAmendment pseudo-transaction could be included in the same ledger as the pseudo-transaction to enable an amendment. In this case, the pseudo-transaction with the `tfLostMajority` pseudo-transaction has no effect.
|
||||
|
||||
## Amendment Voting
|
||||
|
||||
Each version of `rippled` is compiled with a list of known amendments and the code to implement those amendments. Operators of `rippled` validators [configure their servers](configure-amendment-voting.html) to vote in favor or against each inactive amendment. Server operators can change their votes at any time. If the operator does not choose a setting for a particular amendment, the server uses a default vote which is defined in the source code. The default can change in new software releases. For example, version 2.0 of the server might understand a new amendment but vote against it by default; then version 2.1 of the server might vote in favor of the same amendment by default. [Updated in: rippled 1.8.1][]
|
||||
Each version of `rippled` is compiled with a list of known amendments and the code to implement those amendments. Operators of `rippled` validators configure their servers to vote on each amendment and can change it at any time. If the operator doesn't choose a vote, the server uses a default vote defined by the source code.
|
||||
|
||||
To become enabled, an amendment must be supported by more than 80% of trusted validators continuously for two weeks. If support for an amendment goes below 80% of trusted validators, the amendment is temporarily rejected. The two week period starts over if the amendment regains support of more than 80% of trusted validators. (This can occur if validators vote differently, or if there is a change in which validators are trusted.) An amendment can gain and lose a majority any number of times before it becomes permanently enabled.
|
||||
**Note:** The default vote can change between software releases. [Updated in: rippled 1.8.1][]
|
||||
|
||||
An amendment cannot be permanently rejected, but it becomes very unlikely for an amendment to become enabled if new versions of `rippled` do not have the amendment in their known amendments list. Amendments that have had their source code removed without becoming enabled are considered "Vetoed" by the network.
|
||||
Amendments must maintain two weeks of support from more than 80% of trusted validators to be enabled. If support drops below 80%, the amendment is temporarily rejected, and the two week period restarts. Amendments can gain and lose a majority any number of times before it becomes permanently enabled.
|
||||
|
||||
As with all aspects of the consensus process, amendment votes are only taken into account by servers that trust the validators sending those votes. <!-- TODO: link an explanation of validator list publishers when one's ready -->
|
||||
|
||||
For information on how to configure your server's amendment votes, see [Configure Amendment Voting](configure-amendment-voting.html). [Updated in: rippled 1.7.0][]
|
||||
Amendments that have had their source code removed without being enabled are considered **Vetoed** by the network.
|
||||
|
||||
|
||||
## Amendment Blocked
|
||||
## Amendment Blocked Servers
|
||||
|
||||
When an amendment gets enabled for the network after the voting process, servers running earlier versions of `rippled` that do not know about the amendment become "amendment blocked" because they no longer understand the rules of the network. Servers that are amendment blocked:
|
||||
Amendment blocking is a security feature to protect the accuracy of XRP Ledger data. When an amendment is enabled, servers running earlier versions of `rippled` without the amendment's source code no longer understand the rules of the network. Rather than guess and misinterpret ledger data, these servers become **amendment blocked** and can't:
|
||||
|
||||
* Cannot determine the validity of a ledger
|
||||
* Cannot submit or process transactions
|
||||
* Do not participate in the consensus process
|
||||
* Do not vote on future amendments
|
||||
* Determine the validity of a ledger.
|
||||
* Submit or process transactions.
|
||||
* Participate in the consensus process.
|
||||
* Vote on future amendments.
|
||||
|
||||
Becoming amendment blocked is a security feature to protect applications that depend on XRP Ledger data. Rather than guessing and maybe misinterpreting a ledger after new rules have been applied, `rippled` reports that it does not know the state of the ledger because it does not know how the amendment works.
|
||||
The voting configuration of a `rippled` server has no impact on it becoming amendment blocked. A `rippled` server always follows the amendments enabled by the rest of the network, so blockages are based solely on having the code to understand rule changes. This means you can also become amendment blocked if you connect your server to a parallel network with different amendments enabled. For example, the XRP Ledger Devnet typically has experimental amendments enabled. If you are using the latest production release, your server likely won't have the code for those experimental amendments.
|
||||
|
||||
The amendments that a `rippled` server is configured to vote for or against have no impact on whether the server becomes amendment blocked. A `rippled` server always follows the set of amendments enabled by the rest of the network, to the extent possible. A server only becomes amendment blocked if an enabled amendment is not included in the amendment definitions compiled into the server's source code -- in other words, if the amendment is newer than the server.
|
||||
|
||||
If your server is amendment blocked, you must [upgrade to a new version](install-rippled.html) to sync with the network.
|
||||
|
||||
It is also possible to be amendment blocked because you connected your server to a [parallel network](parallel-networks.html) that has different amendments enabled. For example, the XRP Ledger Devnet typically has upcoming and experimental amendments enabled. If you are using the latest production release, your server is likely to be amendment blocked when connecting to Devnet. You could resolve this issue by upgrading to an unstable pre-release or nightly build, or you could [connect to a different network such as Testnet](connect-your-rippled-to-the-xrp-test-net.html) instead.
|
||||
You can unblock amendment blocked servers by upgrading to the newest version of `rippled`.
|
||||
|
||||
|
||||
### How to Tell If Your `rippled` Server Is Amendment Blocked
|
||||
## Retiring Amendments
|
||||
|
||||
One of the first signs that your `rippled` server is amendment blocked is an `amendmentBlocked` error that is returned [when you submit a transaction](submit.html). Here's an example `amendmentBlocked` error:
|
||||
When amendments are enabled, the source code for pre-amendment behaviors remain in `rippled`. While there are use-cases for keeping old code, such as reconstructing ledger outcomes for verification, tracking amendments and legacy code adds complexity over time.
|
||||
|
||||
```json
|
||||
{
|
||||
"result":{
|
||||
"error":"amendmentBlocked",
|
||||
"error_code":14,
|
||||
"error_message":"Amendment blocked, need upgrade.",
|
||||
"request":{
|
||||
"command":"submit",
|
||||
"tx_blob":"479H0KQ4LUUXIHL48WCVN0C9VD7HWSX0MG1UPYNXK6PI9HLGBU2U10K3HPFJSROFEG5VD749WDPHWSHXXO72BOSY2G8TWUDOJNLRTR9LTT8PSOB9NNZ485EY2RD9D80FLDFRBVMP1RKMELILD7I922D6TBCAZK30CSV6KDEDUMYABE0XB9EH8C4LE98LMU91I9ZV2APETJD4AYFEN0VNMIT1XQ122Y2OOXO45GJ737HHM5XX88RY7CXHVWJ5JJ7NYW6T1EEBW9UE0NLB2497YBP9V1XVAEK8JJYVRVW0L03ZDXFY8BBHP6UBU7ZNR0JU9GJQPNHG0DK86S4LLYDN0BTCF4KWV2J4DEB6DAX4BDLNPT87MM75G70DFE9W0R6HRNWCH0X075WHAXPSH7S3CSNXPPA6PDO6UA1RCCZOVZ99H7968Q37HACMD8EZ8SU81V4KNRXM46N520S4FVZNSJHA"
|
||||
},
|
||||
"status":"error"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
The following `rippled` log message also indicates that your server is amendment blocked:
|
||||
|
||||
```
|
||||
2018-Feb-12 19:38:30 LedgerMaster:ERR One or more unsupported amendments activated: server blocked.
|
||||
```
|
||||
|
||||
If you are on `rippled` version 0.80.0+, you can verify that your `rippled` server is amendment blocked using the [`server_info`](server_info.html) command. In the response, look for `result.info.amendment_blocked`. If `amendment_blocked` is set to `true`, your server is amendment blocked.
|
||||
|
||||
**Example JSON-RPC Response:**
|
||||
|
||||
```json
|
||||
{
|
||||
"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"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
If your server is not amendment blocked, the `amendment_blocked` field is not returned in the response.
|
||||
|
||||
**Caution:** `rippled` versions older than 0.80.0 do not include the `amendment_blocked` field, even if your server is amendment blocked.
|
||||
|
||||
|
||||
### How to Unblock an Amendment-Blocked `rippled` Server
|
||||
|
||||
Upgrade to the `rippled` version that supports the amendments that are causing your server to be amendment blocked. Ripple recommends that you [upgrade to the newest `rippled` version](install-rippled.html) to unblock your server and enable it to sync with the network again.
|
||||
|
||||
Depending on the scenario, you may be able to (and want to) unblock your server by upgrading to a `rippled` version that is older than the newest version. This is possible if the older version supports the amendments that are blocking your `rippled` server.
|
||||
|
||||
**Warning:** If the newest `rippled` version provides security or other urgent fixes, you should upgrade to the newest version as soon as possible.
|
||||
|
||||
To determine if you can unblock your `rippled` server by upgrading to a version older than the newest version, find out which features are blocking your server and then look up the `rippled` version that supports the blocking features.
|
||||
|
||||
To find out which features are blocking your `rippled` server, use the [`feature`](feature.html) admin command. Look for features that have `"enabled" : true` and `"supported" : false`. These values for a feature mean that the amendment is currently enabled (required) in the latest ledger, but your server does not know how to support, or apply, the amendment.
|
||||
|
||||
**Example JSON-RPC Response:**
|
||||
|
||||
```json
|
||||
{
|
||||
"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"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
In this example, conflicts with the following features are causing your `rippled` server to be amendment blocked:
|
||||
|
||||
* `157D2D480E006395B76F948E3E07A45A05FE10230D88A7993C71F97AE4B1F2D1`
|
||||
|
||||
* `67A34F2CF55BFC0F93AACD5B281413176FEE195269FA6D95219A2DF738671172`
|
||||
|
||||
* `F64E1EABBE79D55B3BB82020516CEC2C582A98A6BFE20FBE9BB6A0D233418064`
|
||||
|
||||
To look up which `rippled` version supports these features, see [Known Amendments](known-amendments.html).
|
||||
|
||||
|
||||
## Testing Amendments
|
||||
|
||||
If you want to see how `rippled` behaves with an amendment enabled, before that amendment gets enabled on the production network, you can run use `rippled`'s config file to forcibly enable a feature. This is intended for development purposes only.
|
||||
|
||||
Because other members of the consensus network probably do not have the feature enabled, you should not use this feature while connecting to the production network. While testing with features forcibly enabled, you should run `rippled` in [stand-alone mode][].
|
||||
|
||||
To forcibly enable a feature, add a `[features]` stanza to your `rippled.cfg` file. In this stanza, add the short names of the features to enable, one per line. For example:
|
||||
|
||||
```
|
||||
[features]
|
||||
MultiSign
|
||||
TrustSetAuth
|
||||
```
|
||||
|
||||
|
||||
## Retiring Legacy Code
|
||||
|
||||
After an amendment has become enabled, it can never be disabled. (To reverse protocol changes, it would be necessary to create a new amendment.) However, separate ledger chains, such as [test networks](parallel-networks.html) or [stand-alone mode](rippled-server-modes.html#stand-alone-mode) can have different sets of amendments applied. The pre-amendment code may continue to run in those cases, and the software must work with an increasing number of combinations of amendments that may or may not be enabled on any given test network.
|
||||
|
||||
Rather than maintain the source code for all old behavior indefinitely, [XRP Ledger Standard 11d](https://github.com/XRPLF/XRPL-Standards/discussions/19) defines a process for retiring the pre-amendment code. In this process, amendments that have been enabled on the XRP Ledger Mainnet can have the pre-amendment code removed, making them apply unconditionally as part of the XRP Ledger protocol. For the XRP Ledger's [reference server implementation](xrpl-servers.html), the developers periodically chooses a cutoff date **at least 2 years** in the past, and retire pre-amendment source code for amendments that were enabled on the network before the cutoff date. <!-- SPELLING_IGNORE: 11d -->
|
||||
|
||||
When pre-amendment code has been retired, the server follows the amended logic for all transactions at all times. As a result, the server is no longer guaranteed to produce historically-accurate results if you try to replay ledgers older than the cutoff date. The server prints a warning if you try to [load and replay a ledger](load-a-saved-ledger-in-stand-alone-mode.html) that is older than the cutoff date. To produce historically-accurate results, you must compile or download an old server binary that has the legacy code. <!-- STYLE_OVERRIDE: accurate -->
|
||||
The [XRP Ledger Standard 11d](https://github.com/XRPLF/XRPL-Standards/discussions/19) defines a process for retiring old amendments and associated pre-amendment code. After an amendment has been enabled on the Mainnet for two years, it can be retired. Retiring an amendment makes it part of the core protocol unconditionally; it's no longer tracked or treated as an amendment, and all pre-amendment code is removed.
|
||||
|
||||
|
||||
## See Also
|
||||
|
||||
- **Concepts:**
|
||||
- [Known Amendments List](known-amendments.html)
|
||||
- [Introduction to Consensus](intro-to-consensus.html)
|
||||
- **Tutorials:**
|
||||
- [Run rippled as a Validator](run-rippled-as-a-validator.html)
|
||||
- [Configure Amendment Voting](configure-amendment-voting.html)
|
||||
- [Contribute Code to the XRP Ledger](contribute-code.html)
|
||||
- **References:**
|
||||
- [Amendments ledger object](amendments-object.html)
|
||||
- [EnableAmendment pseudo-transaction][]
|
||||
- [feature method][]
|
||||
- [server_info method][]
|
||||
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
|
||||
@@ -81,28 +81,18 @@ Most notably, reporting mode servers do not report pending, non-validated ledger
|
||||
|
||||
## Stand-Alone Mode
|
||||
|
||||
In stand-alone mode, the server operates without attempting to connect to the peer-to-peer network or follow the consensus process. The server still provides API access as normal and uses the same transaction processing engine, so you can test `rippled` behavior without being tied to the live network. For example, you can:
|
||||
In stand-alone mode, the server operates without connecting to the network and participating in the consensus process. Without the consensus process, you have to manually advance the ledger and no distinction is made between "closed" and "validated" ledgers. However, the server still provides API access and processes transactions the same. This enables you to:
|
||||
|
||||
- [Test the effects of Amendments](amendments.html#testing-amendments) before those Amendments have gone into effect across the decentralized network.
|
||||
- [Test the effects of Amendments](test-amendments.html) before those Amendments have gone into effect across the decentralized network.
|
||||
- [Create a new genesis ledger](start-a-new-genesis-ledger-in-stand-alone-mode.html) from scratch.
|
||||
- [Load an existing ledger version](load-a-saved-ledger-in-stand-alone-mode.html) from disk, then replay specific transactions to re-create their outcomes or test other possibilities.
|
||||
|
||||
**Caution:** In stand-alone mode, you must [manually advance the ledger](advance-the-ledger-in-stand-alone-mode.html).
|
||||
|
||||
|
||||
## See Also
|
||||
|
||||
- **References:**
|
||||
- [Commandline Usage Reference](commandline-usage.html) - Detailed information on command-line options for all `rippled` server modes.
|
||||
- [ledger_accept method][] - Manually advance the ledger in stand-alone mode.
|
||||
- [feature method][] - Check [amendments](amendments.html) currently known and enabled.
|
||||
- **Tutorials:**
|
||||
- [Configure `rippled`](configure-rippled.html)
|
||||
- [Run `rippled` as a Validator](run-rippled-as-a-validator.html)
|
||||
- [Use rippled in Stand-Alone Mode](use-stand-alone-mode.html):
|
||||
- [Start a New Genesis Ledger in Stand-Alone Mode](start-a-new-genesis-ledger-in-stand-alone-mode.html)
|
||||
- [Load a Saved Ledger in Stand-Alone Mode](load-a-saved-ledger-in-stand-alone-mode.html)
|
||||
- [Advance the Ledger in Stand-Alone Mode](advance-the-ledger-in-stand-alone-mode.html)
|
||||
- [Use rippled in Stand-Alone Mode](use-stand-alone-mode.html)
|
||||
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
|
||||
@@ -13,6 +13,33 @@ name: よくある質問
|
||||
---
|
||||
# よくある質問
|
||||
|
||||
<!--#{ 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. #}-->
|
||||
#### XRP Ledger(XRPL)はRippleが所有するプライベートブロックチェーンですか？
|
||||
|
||||
いいえ。XRPLは分散型のパブリックブロックチェーンです。トランザクション処理やコンセンサスに影響を与えるような変更は、ネットワークバリデーターの80％以上の承認が必要です。Rippleはネットワークへの貢献者の一員ですが、その権利は他の貢献者たちと同じです。ネットワークには150以上のバリデーターが参加しており、うちデフォルトのユニークノードリスト(UNLs)に登録されているものは35以上です。Rippleはこれらのうち[2つのノード](https://foundation.xrpl.org/2022/10/06/unl-update-october-2022)を運営しています。
|
||||
ユニークノードリスト(UNLs)に関しては[ユニークノードリスト（UNL）とは何ですか?](#ユニークノードリストunlとは何ですか)の項目を参照してください。
|
||||
|
||||
|
||||
#### プルーフ・オブ・ワーク(PoW)が最善の検証メカニズムではないのですか？
|
||||
|
||||
いいえ。プルーフ・オブ・ワークは、信頼できる第三者を必要とせずに二重支出の問題を解決する最初のコンセンサンス・メカニズムでした。[XRP Ledgerのコンセンサス・メカニズム](consensus.html)は、同じ問題をはるかに速く、安く、より良いエネルギー効率で解決します。
|
||||
|
||||
|
||||
#### どのようにして持続可能なブロックチェーンを実現するのでしょうか？
|
||||
|
||||
ビットコインのエネルギー消費量は、2021年現在アルゼンチンのエネルギー総消費量に相当します。また、ビットコインの採掘者が使用する電力の多くは環境を汚染するリソースから供給されていることが広く報告されています。XRPLは、プルーフ・オブ・ワークのようにエネルギーを浪費しない[コンセンサス・メカニズム](intro-to-consensus.html)を通じてトランザクションを承認し、カーボン・オフセットを活用して、[真にカーボンニュートラルな最初のブロックチェーンのひとつ](https://ripple.com/ripple-press/ripple-leads-sustainability-agenda-to-achieve-carbon-neutrality-by-2030)となっています。[グリーン・カレンシー・カルキュレーター](carbon-calculator.html)を利用して、現金、クレジットカード、その他の人気のある暗号通貨と比較したXRPのエネルギー消費量を調べてみてください。
|
||||
|
||||
|
||||
#### XRPLではXRP以外の通貨も取引できますか？
|
||||
|
||||
はい。XRPLは米ドル、ユーロ、石油、金、リワードポイントなど、任意の資産をトークン化できるように構築されており、どんな通貨でもXRPL上で発行することができます。成長中のXRPLコミュニティは様々なフィアットトークンや暗号通貨をサポートしており、これを裏付けています。
|
||||
|
||||
|
||||
#### XRPLは決済用だけではないのですか？
|
||||
|
||||
いいえ。当初は決済のユースケース向けに開発されましたが、台帳であるXRP Ledgerとそのネイティブ・デジタルアセットであるXRPの両方は、NFTなどの様々な革新的ブロックチェーンのユースケースで更に人気を集めています。自動マーケットメーカー(AMM)、XRPL Labsのスマートコントラクト機能に関するフック修正、相互運用サイドチェーンの開発などが現在進行中です。
|
||||
|
||||
|
||||
## バリデータ（検証者）とユニークノードリスト
|
||||
|
||||
<!--#{ 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. #}-->
|
||||
|
||||
@@ -19,7 +19,7 @@ name: FAQ
|
||||
|
||||
#### Is XRPL a private blockchain, owned by Ripple?
|
||||
|
||||
No, the XRP Ledger is a decentralized, public blockchain. Any changes that would impact transaction processing or consensus need to be approved by at least 80%% of the network. Ripple is a contributor to the network, but its rights are the same as those of other contributors. In terms of validation, there are 150+ validators on the network with 35+ on the default Unique Node List (see [“What are Unique Node Lists (UNLs)?” below](#what-are-unique-node-lists-unls)) — Ripple runs 6 of these nodes.
|
||||
No, the XRP Ledger is a decentralized, public blockchain. Any changes that would impact transaction processing or consensus need to be approved by at least 80%% of the network. Ripple is a contributor to the network, but its rights are the same as those of other contributors. In terms of validation, there are 150+ validators on the network with 35+ on the default Unique Node List (see [“What are Unique Node Lists (UNLs)?” below](#what-are-unique-node-lists-unls)) — Ripple runs [only 2](https://foundation.xrpl.org/2022/10/06/unl-update-october-2022) of these nodes.
|
||||
|
||||
#### Isn’t Proof of Work the best validation mechanism?
|
||||
|
||||
@@ -35,8 +35,7 @@ Yes, the XRP Ledger was built specifically to be able to tokenize arbitrary asse
|
||||
|
||||
#### Isn’t XRPL only for payments?
|
||||
|
||||
Although XRPL was initially developed for payment use cases, both the ledger and its native digital asset XRP are increasingly popular for a range of innovative blockchain use cases. New standards proposals for issuing NFTs, XRPL Labs’ hooks amendment for smart contract functionality, and federated sidechains are all currently works in progress.
|
||||
|
||||
Although XRPL was initially developed for payment use cases, both the ledger and its native digital asset XRP are increasingly popular for a range of innovative blockchain use cases such as NFTs. New standards proposals for an automated market maker (AMM), XRPL Labs’ hooks amendment for smart contract functionality, and federated sidechains are all currently works in progress.
|
||||
|
||||
## Validators and Unique Node Lists
|
||||
|
||||
|
||||
130
content/privacy-policy.md
Normal file
130
content/privacy-policy.md
Normal file
@@ -0,0 +1,130 @@
|
||||
---
|
||||
html: privacy-policy.html
|
||||
parent: xrp-ledger-overview.html
|
||||
blurb:
|
||||
subtitle: Privacy Policy
|
||||
top_nav_grouping: About
|
||||
template: page-privacy-policy.html.jinja
|
||||
name: Privacy Policy
|
||||
---
|
||||
# XRPL.org Privacy Policy
|
||||
|
||||
Last updated: Jan 20, 2023
|
||||
|
||||
MTU XRP Ledger Trust (“MTU XRP Ledger Trust”, “We”, “Our”, “Us”) respects our users’ need for privacy, and this Privacy Policy describes the collection, use and disclosure of Your information when You use this Service.
|
||||
|
||||
## Definitions
|
||||
|
||||
For the purposes of this Privacy Policy:
|
||||
|
||||
* _Company_ - (referred to as either "MTU XRP Ledger Trust", "We", "Us" or "Our" in this policy) refers to XRPL.org
|
||||
* _Cookies_ - are small files that are placed on Your computer, mobile device or any other device by a website, containing the details of Your browsing history on that website among its many uses.
|
||||
* _Device_ - means any device that can access the Service such as a computer, a mobile phone or a digital tablet.
|
||||
* _Personal Data_ - is any information that relates to an identified or identifiable individual.
|
||||
* _Service_ - refers to this XRPL.org website.
|
||||
* _Service Provider_ - means any natural or legal person who processes the data on behalf of MTU XRP Ledger Trust. It refers to third-party companies or individuals employed by MTU XRP Ledger Trust to facilitate the Service, to provide the Service on behalf of MTU XRP Ledger Trust, to perform services related to the Service or to assist MTU XRP Ledger Trust in analyzing how the Service is used.
|
||||
* _Usage Data_ - refers to data collected automatically, either generated by the use of the Service or from the Service infrastructure itself (for example, the duration of a page visit).
|
||||
* _You_ - means the individual accessing or using the Service, or MTU XRP Ledger Trust, or other legal entity on behalf of which such individual is accessing or using the Service, as applicable.
|
||||
|
||||
## Collecting and Using Your Data
|
||||
|
||||
### Types of Data Collected
|
||||
|
||||
**Usage Data** is automatically collected when using this Service. Usage Data may include information such as Your Device's Internet Protocol address (e.g. IP address), browser type, browser version, the pages of our Service that You visit, the time and date of Your visit, the time spent on those pages, unique device identifiers and other diagnostic data.
|
||||
|
||||
When You access the Service by or through a mobile device, We may collect certain information automatically, including, but not limited to, the type of mobile device You use, Your mobile device unique ID, the IP address of Your mobile device, Your mobile operating system, the type of mobile Internet browser You use, unique device identifiers and other diagnostic data.
|
||||
|
||||
We may also collect information that Your browser sends whenever You visit our Service or when You access the Service by or through a mobile device.
|
||||
|
||||
## Tracking Technologies and Cookies
|
||||
|
||||
We use Cookies and similar tracking technologies to track the activity on Our Service and store certain information. Tracking technologies used are beacons, tags, and scripts to collect and track information and to improve and analyze Our Service. The technologies We use may include:
|
||||
|
||||
* _Cookies or Browser Cookies_ - A cookie is a small file placed on Your Device. You can instruct Your browser to refuse all Cookies or to indicate when a Cookie is being sent. However, if You do not accept Cookies, You may not be able to use some parts of our Service. Unless you have adjusted Your browser setting so that it will refuse Cookies, our Service may use Cookies.
|
||||
* _Flash Cookies_ - Certain features of our Service may use local stored objects (or Flash Cookies) to collect and store information about Your preferences or Your activity on our Service. Flash Cookies are not managed by the same browser settings as those used for Browser Cookies.
|
||||
* _Web Beacons_ - Certain sections of our Service may contain small electronic files known as web beacons (also referred to as clear gifs, pixel tags, and single-pixel gifs) that permit the Company, for example, to count users who have visited those pages or opened an email and for other related website statistics (for example, recording the popularity of a certain section and verifying system and server integrity).
|
||||
|
||||
Cookies can be "Persistent" or "Session" Cookies. Persistent Cookies remain on Your personal computer or mobile device when You go offline, while Session Cookies are deleted as soon as You close Your web browser.
|
||||
|
||||
## Use of Your Usage Data
|
||||
|
||||
The Company may use Usage Data for the following purposes:
|
||||
|
||||
**To provide and maintain our Service**, including to monitor the usage of our Service.
|
||||
**To manage Your requests:** To attend and manage Your requests to Us.
|
||||
|
||||
**For other purposes:** We may use Your Usage Data for other purposes, such as data analysis, identifying usage trends, determining the effectiveness of our promotional campaigns and to evaluate and improve our Service and your experience.
|
||||
|
||||
We may share Your Usage Data in the following situations:
|
||||
|
||||
**With Service Providers:** We may share Your Usage Data with Service Providers to monitor and analyze the use of our Service.
|
||||
|
||||
**With business partners:** We may share Your Usage Data with Our business partners who provide content on this website.
|
||||
|
||||
**With Your consent:** We may disclose Your Usage Data for any other purpose with Your consent.
|
||||
|
||||
## Retention of Your Usage Data
|
||||
|
||||
The Company will retain Your Usage Data only for as long as is necessary for the purposes set out in this Privacy Policy. We will retain and use Your Usage Data to the extent necessary to comply with our legal obligations (for example, if we are required to retain your data to comply with applicable laws, strengthen the security or to improve the functionality of Our Service, resolve disputes, and enforce our legal agreements and policies.
|
||||
|
||||
## Transfer of Your Usage Data
|
||||
|
||||
Your Usage Data is processed at the Company's operating offices and in any other places where the parties involved in the processing are located. It means that this information may be transferred to — and maintained on — computers located outside of Your state, province, country or other governmental jurisdiction where the data protection laws may differ from those from Your jurisdiction.
|
||||
|
||||
Your consent to this Privacy Policy followed by Your submission of such information represents Your agreement to that transfer.
|
||||
|
||||
## Disclosure of Your Usage Data
|
||||
|
||||
## Law enforcement
|
||||
|
||||
Under certain circumstances, the Company may be required to disclose Your Usage Data if required to do so by law or in response to valid requests by public authorities (e.g. a court or a government agency).
|
||||
|
||||
## Other legal requirements
|
||||
|
||||
The Company may disclose Your Usage Data in the good faith belief that such action is necessary to:
|
||||
|
||||
* Comply with a legal obligation
|
||||
* Protect and defend the rights or property of the Company
|
||||
* Prevent or investigate possible wrongdoing in connection with the Service
|
||||
* Protect the personal safety of Users of the Service or the public
|
||||
* Protect against legal liability
|
||||
|
||||
## Security of Your Personal Data
|
||||
|
||||
The security of Your Data is important to Us, but remember that no method of transmission over the Internet, or method of electronic storage is 100% secure. While We strive to use commercially acceptable means to protect Your Data, We cannot guarantee its absolute security.
|
||||
|
||||
## Children's Privacy
|
||||
|
||||
Our Service does not address anyone under the age of 13. We do not knowingly collect personally identifiable information from anyone under the age of 13. If You are a parent or guardian and You are aware that Your child has provided Us with Personal Data, please contact Us. If We become aware that We have collected Personal Data from anyone under the age of 13 without verification of parental consent, We take steps to remove that information from Our servers.
|
||||
|
||||
If We need to rely on consent as a legal basis for processing Your information and Your country requires consent from a parent, We may require Your parent's consent before We collect and use that information.
|
||||
|
||||
## Links to Other Websites
|
||||
|
||||
Our Service may contain links to other websites that are not operated by Us. If You click on a third party link, You will be directed to that third party's site. We strongly advise You to review the Privacy Policy of every site You visit.
|
||||
|
||||
We have no control over and assume no responsibility for the content, privacy policies or practices of any third party sites or services.
|
||||
|
||||
## Changes to this Privacy Policy
|
||||
|
||||
We may update Our Privacy Policy from time to time. We will notify You of any changes by posting the new Privacy Policy on this page. We will provide a prominent notice on Our Service, prior to the change becoming effective and update the "Last updated" date at the top of this Privacy Policy.
|
||||
|
||||
You are advised to review this Privacy Policy periodically for any changes. Changes to this Privacy Policy are effective when they are posted on this page.
|
||||
|
||||
## Contact Us
|
||||
|
||||
If you have any questions about this Privacy Policy, You can contact us:
|
||||
|
||||
MTU XRP Ledger Trust
|
||||
|
||||
**Regd Office**
|
||||
15, Ringtee
|
||||
Kuressaare
|
||||
Estonia 93815
|
||||
|
||||
**Tallinn Office**
|
||||
802, Lõõtsa tn 5
|
||||
Tallinn
|
||||
Estonia 11415
|
||||
|
||||
**By email:** info@xrplf.org
|
||||
@@ -187,7 +187,7 @@ The response follows the [standard format][], with a successful result containin
|
||||
|:------------|:--------|:-----------------------------------------------------|
|
||||
| `enabled` | Boolean | Whether this amendment is currently enabled in the latest ledger. |
|
||||
| `name` | String | (May be omitted) The human-readable name for this amendment, if known. |
|
||||
| `supported` | Boolean | Whether the server knows how to apply this amendment. If this field is set to `false` (the server does not know how to apply this amendment) and `enabled` is set to `true` (this amendment is enabled in the latest ledger), this amendment may cause your server to be [amendment blocked](amendments.html#amendment-blocked). |
|
||||
| `supported` | Boolean | Whether the server knows how to apply this amendment. If this field is set to `false` (the server does not know how to apply this amendment) and `enabled` is set to `true` (this amendment is enabled in the latest ledger), this amendment may cause your server to be [amendment blocked](amendments.html#amendment-blocked-servers). |
|
||||
| `vetoed` | Boolean | Whether the server has been instructed to vote against this amendment. |
|
||||
|
||||
**Caution:** The `name` for an amendment does not strictly indicate what that amendment does. The name is not guaranteed to be unique or consistent across servers.
|
||||
|
||||
@@ -108,7 +108,7 @@ For other errors that returned with HTTP status code 200 OK, the responses are f
|
||||
|
||||
All methods can potentially return any of the following values for the `error` code:
|
||||
|
||||
- `amendmentBlocked` - The server is [amendment blocked](amendments.html#amendment-blocked) and needs to be updated to the latest version to stay synced with the XRP Ledger network.
|
||||
- `amendmentBlocked` - The server is [amendment blocked](amendments.html#amendment-blocked-servers) and needs to be updated to the latest version to stay synced with the XRP Ledger network.
|
||||
- `failedToForward` - ([Reporting Mode][] servers only) The server tried to forward this request to a P2P Mode server, but the connection failed.
|
||||
- `invalid_API_version` - The server does not support the [API version number](request-formatting.html#api-versioning) from the request.
|
||||
- `jsonInvalid` - (WebSocket only) The request is not a proper JSON object.
|
||||
|
||||
@@ -126,7 +126,7 @@ Example warning:
|
||||
]
|
||||
```
|
||||
|
||||
This warning indicates that the one or more [amendments](amendments.html) to the XRP Ledger protocol are scheduled to become enabled, but the current server does not have an implementation for those amendments. If those amendments become enabled, the current server will become [amendment blocked](amendments.html#amendment-blocked), so you should [upgrade to the latest `rippled` version](install-rippled.html) as soon as possible. <!-- STYLE_OVERRIDE: will -->
|
||||
This warning indicates that the one or more [amendments](amendments.html) to the XRP Ledger protocol are scheduled to become enabled, but the current server does not have an implementation for those amendments. If those amendments become enabled, the current server will become [amendment blocked](amendments.html#amendment-blocked-servers), so you should [upgrade to the latest `rippled` version](install-rippled.html) as soon as possible. <!-- STYLE_OVERRIDE: will -->
|
||||
|
||||
The server only sends this warning if the client is [connected as an admin](get-started-using-http-websocket-apis.html#admin-access).
|
||||
|
||||
@@ -153,7 +153,7 @@ Example warning:
|
||||
]
|
||||
```
|
||||
|
||||
This warning indicates that the server is [amendment blocked](amendments.html#amendment-blocked) and can no longer remain synced with the XRP Ledger.
|
||||
This warning indicates that the server is [amendment blocked](amendments.html#amendment-blocked-servers) and can no longer remain synced with the XRP Ledger.
|
||||
|
||||
The server administrator must [upgrade `rippled`](install-rippled.html) to a version that supports the activated amendments.
|
||||
|
||||
|
||||
@@ -0,0 +1,116 @@
|
||||
---
|
||||
html: health-check.html
|
||||
parent: peer-port-methods.html
|
||||
blurb: Special API method for reporting server health.
|
||||
labels:
|
||||
- Core Server
|
||||
---
|
||||
# Health Check
|
||||
[[Source]](https://github.com/ripple/rippled/blob/de0c52738785de8bf837f9124da65c7905e7bb5a/src/ripple/overlay/impl/OverlayImpl.cpp#L1084-L1168 "Source")
|
||||
|
||||
The Health Check is a special [peer port method](peer-port-methods.html) for reporting on the health of an individual `rippled` server. This method is intended for use in automated monitoring to recognize outages and prompt automated or manual interventions such as restarting the server. [New in: rippled 1.6.0][]
|
||||
|
||||
This method checks several metrics to see if they are in ranges generally considered healthy. If all metrics are in normal ranges, this method reports that the server is healthy. If any metric is outside normal ranges, this method reports that the server is unhealthy and reports the metric(s) that are unhealthy. Since some metrics may rapidly fluctuate into and out of unhealthy ranges, you should not raise alerts unless the health check fails multiple times in a row.
|
||||
|
||||
**Note:** Since the health check is a [peer port method](peer-port-methods.html), it is not available when testing the server in [stand-alone mode][].
|
||||
|
||||
|
||||
## Request Format
|
||||
|
||||
To request the Health Check information, make the following HTTP request:
|
||||
|
||||
- **Protocol:** https
|
||||
- **HTTP Method:** GET
|
||||
- **Host:** (any `rippled` server, by hostname or IP address)
|
||||
- **Port:** (the port number where the `rippled` server uses the Peer Protocol, typically 51235)
|
||||
- **Path:** `/health`
|
||||
- **Security:** Most `rippled` servers use a self-signed certificate to respond to the request. By default, most tools (including web browsers) flag or block such responses for being untrusted. You must ignore the certificate checking (for example, if using cURL, add the `--insecure` flag) to display a response from those servers.
|
||||
|
||||
<!-- TODO: link a tutorial for how to run rippled with a non-self-signed TLS cert -->
|
||||
|
||||
## Example Response
|
||||
|
||||
<!-- MULTICODE_BLOCK_START -->
|
||||
|
||||
*Healthy*
|
||||
|
||||
```json
|
||||
HTTP/1.1 200 OK
|
||||
Server: rippled-1.6.0-b8
|
||||
Content-Type: application/json
|
||||
Connection: close
|
||||
Transfer-Encoding: chunked
|
||||
|
||||
{
|
||||
"info": {}
|
||||
}
|
||||
```
|
||||
|
||||
*Warning*
|
||||
|
||||
```json
|
||||
HTTP/1.1 503 Service Unavailable
|
||||
Server: rippled-1.6.0
|
||||
Content-Type: application/json
|
||||
Connection: close
|
||||
Transfer-Encoding: chunked
|
||||
|
||||
{
|
||||
"info": {
|
||||
"server_state": "connected",
|
||||
"validated_ledger": -1
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
*Critical*
|
||||
|
||||
```json
|
||||
HTTP/1.1 500 Internal Server Error
|
||||
Server: rippled-1.6.0
|
||||
Content-Type: application/json
|
||||
Connection: close
|
||||
Transfer-Encoding: chunked
|
||||
|
||||
{
|
||||
"info": {
|
||||
"peers": 0,
|
||||
"server_state": "disconnected",
|
||||
"validated_ledger":-1
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
|
||||
## Response Format
|
||||
|
||||
The response's HTTP status code indicates the health of the server:
|
||||
|
||||
| Status Code | Health Status | Description |
|
||||
|:------------------------------|:--------------|:-----------------------------|
|
||||
| **200 OK** | Healthy | All health metrics are within acceptable ranges. |
|
||||
| **503 Service Unavailable** | Warning | One or more metrics are in the warning range. Manual intervention may or may not be necessary. |
|
||||
| **500 Internal Server Error** | Critical | One or more metrics are in the critical range. There is a serious problem that probably needs manual intervention to fix. |
|
||||
|
||||
The response body is a JSON object with a single `info` object at the top level. The `info` object contains values for each metric that is in a warning or critical range. The response omits metrics that are in a healthy range, so a fully healthy server has an empty object.
|
||||
|
||||
The `info` object may contain the following fields:
|
||||
|
||||
| `Field` | Value | Description |
|
||||
|:--------------------|:--------|:---------------------------------------------|
|
||||
| `amendment_blocked` | Boolean | _(May be omitted)_ If `true`, the server is [amendment blocked](amendments.html#amendment-blocked) and must be upgraded to remain synced with the network; this state is critical. If the server is not amendment blocked, this field is omitted. |
|
||||
| `load_factor` | Number | _(May be omitted)_ A measure of the overall load the server is under. This reflects I/O, CPU, and memory limitations. This is a warning if the load factor is over 100, or critical if the load factor is 1000 or higher. |
|
||||
| `peers` | Number | _(May be omitted)_ The number of [peer servers](peer-protocol.html) this server is connected to. This is a warning if connected to 7 or fewer peers, and critical if connected to zero peers. |
|
||||
| `server_state` | String | _(May be omitted)_ The current [server state](rippled-server-states.html). This is a warning if the server is in the `tracking`, `syncing`, or `connected` states. This is critical if the server is in the `disconnected` state. |
|
||||
| `validated_ledger` | Number | _(May be omitted)_ The number of seconds since the last time a ledger was validated by [consensus](intro-to-consensus.html). If there is no validated ledger available ([as during the initial sync period when starting the server](server-doesnt-sync.html#normal-syncing-behavior)), this is the value `-1` and is considered a warning. This metric is also a warning if the last validated ledger was at least 7 seconds ago, or critical if the last validated ledger was at least 20 seconds ago. |
|
||||
|
||||
## See Also
|
||||
|
||||
For guidance interpreting the results of the health check, see [Health Check Interventions](health-check-interventions.html).
|
||||
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
{% include '_snippets/tx-type-links.md' %}
|
||||
{% include '_snippets/rippled_versions.md' %}
|
||||
@@ -90,8 +90,8 @@ The response's HTTP status code indicates the health of the server:
|
||||
| Status Code | Health Status | Description |
|
||||
|:------------------------------|:--------------|:-----------------------------|
|
||||
| **200 OK** | Healthy | All health metrics are within acceptable ranges. |
|
||||
| **503 Service Unavailable** | Warning | One or more metric is in the warning range. Manual intervention may or may not be necessary. |
|
||||
| **500 Internal Server Error** | Critical | One or more metric is in the critical range. There is a serious problem that probably needs manual intervention to fix. |
|
||||
| **503 Service Unavailable** | Warning | One or more metrics are in the warning range. Manual intervention may or may not be necessary. |
|
||||
| **500 Internal Server Error** | Critical | One or more metrics are in the critical range. There is a serious problem that probably needs manual intervention to fix. |
|
||||
|
||||
The response body is a JSON object with a single `info` object at the top level. The `info` object contains values for each metric that is in a warning or critical range. The response omits metrics that are in a healthy range, so a fully healthy server has an empty object.
|
||||
|
||||
@@ -99,7 +99,7 @@ The `info` object may contain the following fields:
|
||||
|
||||
| `Field` | Value | Description |
|
||||
|:--------------------|:--------|:---------------------------------------------|
|
||||
| `amendment_blocked` | Boolean | _(May be omitted)_ If `true`, the server is [amendment blocked](amendments.html#amendment-blocked) and must be upgraded to remain synced with the network; this state is critical. If the server is not amendment blocked, this field is omitted. |
|
||||
| `amendment_blocked` | Boolean | _(May be omitted)_ If `true`, the server is [amendment blocked](amendments.html#amendment-blocked-servers) and must be upgraded to remain synced with the network; this state is critical. If the server is not amendment blocked, this field is omitted. |
|
||||
| `load_factor` | Number | _(May be omitted)_ A measure of the overall load the server is under. This reflects I/O, CPU, and memory limitations. This is a warning if the load factor is over 100, or critical if the load factor is 1000 or higher. |
|
||||
| `peers` | Number | _(May be omitted)_ The number of [peer servers](peer-protocol.html) this server is connected to. This is a warning if connected to 7 or fewer peers, and critical if connected to zero peers. |
|
||||
| `server_state` | String | _(May be omitted)_ The current [server state](rippled-server-states.html). This is a warning if the server is in the `tracking`, `syncing`, or `connected` states. This is critical if the server is in the `disconnected` state. |
|
||||
|
||||
@@ -74,7 +74,7 @@ The request includes the following parameters:
|
||||
| `Field` | Type | Description |
|
||||
|:-------------------------|:-----------------|:-------------------------------|
|
||||
| `account` | String | A unique identifier for the account, most commonly the account's address. |
|
||||
| `type` | String | _(Optional)_ If included, filter results to include only this type of ledger object. The valid types are: `check`, `deposit_preauth`, `escrow`, `offer`, `payment_channel`, `signer_list`, `ticket`, and `state` (trust line). <!-- Author's note: Omitted types that can't be owned by an account --> |
|
||||
| `type` | String | _(Optional)_ If included, filter results to include only this type of ledger object. The valid types are: `check`, `deposit_preauth`, `escrow`, `offer`, `payment_channel`, `signer_list`, `ticket`, `state` (trust line), and `nft_offer`. <!-- Author's note: Omitted types that can't be owned by an account --> |
|
||||
| `deletion_blockers_only` | Boolean | _(Optional)_ If `true`, the response only includes objects that would block this account from [being deleted](accounts.html#deletion-of-accounts). The default is `false`. [New in: rippled 1.4.0][] |
|
||||
| `ledger_hash` | String | _(Optional)_ A 20-byte hex string for the ledger version to use. (See [Specifying Ledgers][]) |
|
||||
| `ledger_index` | String or Number | _(Optional)_ The [ledger index][] of the ledger to use, or a shortcut string to choose a ledger automatically. (See [Specifying Ledgers][]) |
|
||||
|
||||
@@ -258,7 +258,7 @@ The `info` object may have some arrangement of the following fields:
|
||||
|
||||
| `Field` | Type | Description |
|
||||
|:------------------------------------|:----------------|:---------------------|
|
||||
| `amendment_blocked` | Boolean | _(May be omitted)_ If `true`, this server is [amendment blocked](amendments.html#amendment-blocked). If the server is not amendment blocked, the response omits this field. [New in: rippled 0.80.0][] |
|
||||
| `amendment_blocked` | Boolean | _(May be omitted)_ If `true`, this server is [amendment blocked](amendments.html#amendment-blocked-servers). If the server is not amendment blocked, the response omits this field. [New in: rippled 0.80.0][] |
|
||||
| `build_version` | String | The version number of the running `rippled` server. |
|
||||
| `closed_ledger` | Object | _(May be omitted)_ Information on the most recently closed ledger that has not been validated by consensus. If the most recently validated ledger is available, the response omits this field and includes `validated_ledger` instead. The member fields are the same as the `validated_ledger` field. |
|
||||
| `complete_ledgers` | String | Range expression indicating the sequence numbers of the ledger versions the local `rippled` has in its database. This may be a disjoint sequence such as `24900901-24900984,24901116-24901158`. If the server does not have any complete ledgers (for example, it recently started syncing with the network), this is the string `empty`. |
|
||||
|
||||
@@ -268,7 +268,7 @@ The `state` object may have some arrangement of the following fields:
|
||||
|
||||
| `Field` | Type | Description |
|
||||
|:---------------------------------|:----------------|:------------------------|
|
||||
| `amendment_blocked` | Boolean | _(May be omitted)_ If `true`, this server is [amendment blocked](amendments.html#amendment-blocked). If the server is not amendment blocked, the response omits this field. [New in: rippled 0.80.0][] |
|
||||
| `amendment_blocked` | Boolean | _(May be omitted)_ If `true`, this server is [amendment blocked](amendments.html#amendment-blocked-servers). If the server is not amendment blocked, the response omits this field. [New in: rippled 0.80.0][] |
|
||||
| `build_version` | String | The version number of the running `rippled` version. |
|
||||
| `complete_ledgers` | String | Range expression indicating the sequence numbers of the ledger versions the local `rippled` has in its database. It is possible to be a disjoint sequence, e.g. "2500-5000,32570-7695432". If the server does not have any complete ledgers (for example, it recently started syncing with the network), this is the string `empty`. |
|
||||
| `closed_ledger` | Object | _(May be omitted)_ Information on the most recently closed ledger that has not been validated by consensus. If the most recently validated ledger is available, the response omits this field and includes `validated_ledger` instead. The member fields are the same as the `validated_ledger` field. |
|
||||
|
||||
@@ -319,7 +319,7 @@ The response follows the [standard format][], with a successful result containin
|
||||
## Possible Errors
|
||||
|
||||
* Any of the [universal error types][].
|
||||
* `amendmentBlocked` - The transaction cannot be submitted to the network because the `rippled` server is [amendment blocked](amendments.html#amendment-blocked).
|
||||
* `amendmentBlocked` - The transaction cannot be submitted to the network because the `rippled` server is [amendment blocked](amendments.html#amendment-blocked-servers).
|
||||
* `highFee` - The `fee_mult_max` parameter was specified, but the server's current fee multiplier exceeds the specified one. (Sign-and-Submit mode only)
|
||||
* `internalJson` - An internal error occurred when serializing the transaction to JSON. This could be caused by many aspects of the transaction, including a bad signature or some fields being malformed.
|
||||
* `internalSubmit` - An internal error occurred when submitting the transaction. This could be caused by many aspects of the transaction, including a bad signature or some fields being malformed.
|
||||
|
||||
@@ -38,7 +38,7 @@ The `Amendments` object type contains a list of [Amendments](amendments.html) th
|
||||
|
||||
| Name | JSON Type | [Internal Type][] | Required? | Description |
|
||||
|-------------------|-----------|-------------------|-----------|-------------|
|
||||
| `Amendments` | Array | Vector256 | No | Array of 256-bit [amendment IDs](amendments.html#about-amendments) for all currently-enabled amendments. If omitted, there are no enabled amendments. |
|
||||
| `Amendments` | Array | Vector256 | No | Array of 256-bit [amendment IDs](amendments.html) for all currently enabled amendments. If omitted, there are no enabled amendments. |
|
||||
| `Flags` | Number | UInt32 | Yes | A bit-map of boolean flags enabled for this object. Currently, the protocol defines no flags for `Amendments` objects. The value is always `0`. |
|
||||
| `LedgerEntryType` | String | UInt16 | Yes | The value `0x0066`, mapped to the string `Amendments`, indicates that this object describes the status of amendments to the XRP Ledger. |
|
||||
| `Majorities` | Array | STArray | No | Array of objects describing the status of amendments that have majority support but are not yet enabled. If omitted, there are no pending amendments with majority support. |
|
||||
|
||||
@@ -7,14 +7,22 @@ labels:
|
||||
---
|
||||
# EnableAmendment
|
||||
|
||||
An `EnableAmendment` [pseudo-transaction](pseudo-transaction-types.html) marks a change in status of an [amendment](amendments.html) to the XRP Ledger protocol, including:
|
||||
An `EnableAmendment` pseudo-transaction marks a change in the status of a proposed amendment when it:
|
||||
|
||||
- A proposed amendment gained supermajority approval from validators.
|
||||
- A proposed amendment lost supermajority approval.
|
||||
- A proposed amendment has been enabled.
|
||||
- Gains supermajority approval from validators.
|
||||
- Loses supermajority approval.
|
||||
- Is enabled on the XRP Ledger protocol.
|
||||
|
||||
**Note:** You cannot send a pseudo-transaction, but you may find one when processing ledgers.
|
||||
<!-- TODO: Move to propose amendments tutorial.
|
||||
|
||||
A server only enables amendments when these conditions are met:
|
||||
|
||||
- A previous ledger includes an `EnableAmendment` pseudo-transaction with the `tfGotMajority` flag enabled.
|
||||
- The previous ledger in question is an ancestor of the current ledger.
|
||||
- The previous ledger in question has a close time that is at least two weeks before the close time of the latest flag ledger.
|
||||
- There are no `EnableAmendment` pseudo-transactions for this amendment with the `tfLostMajority` flag enabled in the consensus ledgers between the `tfGotMajority` pseudo-transaction and the current ledger.
|
||||
|
||||
-->
|
||||
|
||||
## Example {{currentpage.name}} JSON
|
||||
|
||||
|
||||
@@ -14,7 +14,6 @@ If you don't [run your own `rippled` server](install-rippled.html), you can use
|
||||
| XRP Ledger Foundation | **Mainnet** | `https://xrplcluster.com/` <br> `https://xrpl.ws/` [²][] | `wss://xrplcluster.com/` <br> `wss://xrpl.ws/` [²][] | Full history server cluster with CORS support. |
|
||||
| Ripple[¹][] | **Mainnet** | `https://s1.ripple.com:51234/` | `wss://s1.ripple.com/` | General purpose server cluster |
|
||||
| Ripple[¹][] | **Mainnet** | `https://s2.ripple.com:51234/` | `wss://s2.ripple.com/` | [Full-history server](ledger-history.html#full-history) cluster |
|
||||
| Sologenic | **Mainnet** | | `wss://x1.sologenic.org` | Websocket Server |
|
||||
| Ripple[¹][] | Testnet | `https://s.altnet.rippletest.net:51234/` | `wss://s.altnet.rippletest.net/` | Testnet public server |
|
||||
| XRPL Labs | Testnet | `https://testnet.xrpl-labs.com/` | `wss://testnet.xrpl-labs.com/` | Testnet public server with CORS support |
|
||||
| Ripple[¹][] | Devnet | `https://s.devnet.rippletest.net:51234/` | `wss://s.devnet.rippletest.net/` | Devnet public server |
|
||||
|
||||
@@ -0,0 +1,26 @@
|
||||
---
|
||||
html: test-amendments.html
|
||||
parent: configure-rippled.html
|
||||
blurb: You can test proposed amendments before they're enabled on the network.
|
||||
labels:
|
||||
- Blockchain
|
||||
---
|
||||
# Test Amendments
|
||||
|
||||
|
||||
You can test how `rippled` behaves before proposed amendments are fully enabled on the production network. Since other members of the consensus network won't have the feature enabled, run your server in stand-alone mode.
|
||||
|
||||
**Caution:** This is intended for development purposes only.
|
||||
|
||||
To forcibly enable a feature, add a `[features]` stanza with amendment short names to your `rippled.cfg` file. Each amendment needs its own line.
|
||||
|
||||
<!-- MULTICODE_BLOCK_START -->
|
||||
_Example_
|
||||
|
||||
```
|
||||
[features]
|
||||
MultiSign
|
||||
TrustSetAuth
|
||||
```
|
||||
|
||||
<!-- MULTICODE_BLOCK_END -->
|
||||
@@ -15,22 +15,17 @@ rippled ledger_accept --conf=/path/to/rippled.cfg
|
||||
|
||||
In stand-alone mode, `rippled` makes no distinction between a "closed" ledger version and a "validated" ledger version. (For more information about the difference, see [The XRP Ledger Consensus Process](consensus.html).)
|
||||
|
||||
Whenever `rippled` closes a ledger, it reorders the transactions according to a deterministic but hard-to-game algorithm. (This is an important part of consensus, since transactions may arrive at different parts of the network in different order.) When using `rippled` in stand-alone mode, you should manually advance the ledger before submitting a transaction that depends on the result of a transaction from a different address. Otherwise, the two transactions might be executed in reverse order when the ledger is closed. **Note:** You can safely submit multiple transactions from a single address to a single ledger, because `rippled` sorts transactions from the same address in ascending order by [`Sequence` number](transaction-common-fields.html).
|
||||
Whenever `rippled` closes a ledger, it reorders the transactions according to a deterministic but hard-to-game algorithm. (This is an important part of consensus, since transactions may arrive at different parts of the network in different order.) When using `rippled` in stand-alone mode, you should manually advance the ledger before submitting a transaction that depends on the result of a transaction from a different address. Otherwise, the two transactions might be executed in reverse order when the ledger is closed.
|
||||
|
||||
**Note:** You can safely submit multiple transactions from a single address to a single ledger, because `rippled` sorts transactions from the same address in ascending order by [`Sequence` number](transaction-common-fields.html).
|
||||
|
||||
|
||||
## See Also
|
||||
|
||||
- **Concepts:**
|
||||
- [The `rippled` Server](xrpl-servers.html)
|
||||
- [`rippled` Server Modes](rippled-server-modes.html)
|
||||
- [Introduction to Consensus](intro-to-consensus.html)
|
||||
- [Amendments](amendments.html)
|
||||
- **References:**
|
||||
- [ledger_accept method][]
|
||||
- [server_info method][]
|
||||
- [`rippled` Commandline Usage](commandline-usage.html)
|
||||
- **Use Cases:**
|
||||
- [Contribute Code to the XRP Ledger](contribute-code.html)
|
||||
|
||||
<!--{# common link defs #}-->
|
||||
{% include '_snippets/rippled-api-links.md' %}
|
||||
|
||||
@@ -9,7 +9,9 @@ labels:
|
||||
|
||||
You can start a `rippled` server in [Stand-Alone Mode](rippled-server-modes.html) using a [historical ledger version](ledgers.html) that was previously saved to disk. For example, if your `rippled` server was previously synced with any XRP Ledger peer-to-peer network including [the production Mainnet, the Testnet, or the Devnet](parallel-networks.html), you can load any ledger version your server had available.
|
||||
|
||||
Loading a historical ledger version so may be useful for "replaying" a ledger to verify that transactions were processed according to the rules of the network, or to compare the results of processing transaction sets with different [amendments](amendments.html) enabled. In the unlikely event that [an attack against the XRP Ledger's consensus mechanism](consensus-protections.html) caused unwanted effects to the shared ledger state, a consensus of validators could "roll back" to a previous, known-good network state starting with this process.
|
||||
Loading a historical ledger version is useful for "replaying" a ledger to verify that transactions were processed according to the rules of the network, or to compare the results of processing transaction sets with different [amendments](amendments.html) enabled. In the unlikely event that [an attack against the XRP Ledger's consensus mechanism](consensus-protections.html) caused unwanted effects to the shared ledger state, a consensus of validators could "roll back" to a known-good network state starting with this process.
|
||||
|
||||
**Caution:** As `rippled` is updated to newer versions, amendments are retired and become core functions of the ledger, which can affect how transactions are processed. To produce historically accurate results, you need to replay ledgers using the version of `rippled` the transaction was processed in.
|
||||
|
||||
## 1. Start `rippled` normally.
|
||||
|
||||
@@ -63,20 +65,17 @@ For more information on the options you can use when starting `rippled` in stand
|
||||
|
||||
## 6. Manually advance the ledger.
|
||||
|
||||
When you load a ledger with `--ledger` in stand-alone mode, it goes to the current open ledger, so you must [manually advance the ledger](advance-the-ledger-in-stand-alone-mode.html):
|
||||
In stand-alone mode, you must manually advance the ledger with the `ledger_accept` method:
|
||||
|
||||
```
|
||||
rippled ledger_accept --conf=/path/to/rippled.cfg
|
||||
```
|
||||
|
||||
If a transaction depends on the result of a transaction from a different address, advance the ledger to ensure they are processed in the correct order. Otherwise, you can submit multiple transactions from a single address `rippled` sorts transactions from the same address by ascending `Sequence` number.
|
||||
|
||||
|
||||
## See Also
|
||||
|
||||
- **Concepts:**
|
||||
- [The `rippled` Server](xrpl-servers.html)
|
||||
- [`rippled` Server Modes](rippled-server-modes.html)
|
||||
- [Introduction to Consensus](intro-to-consensus.html)
|
||||
- [Amendments](amendments.html)
|
||||
- **References:**
|
||||
- [ledger_accept method][]
|
||||
- [server_info method][]
|
||||
|
||||
@@ -0,0 +1,130 @@
|
||||
---
|
||||
html: server-is-amendment-blocked.html
|
||||
parent: troubleshoot-the-rippled-server.html
|
||||
blurb: Troubleshoot a server that can't implement amendment changes.
|
||||
labels:
|
||||
- Core Server
|
||||
---
|
||||
# rippled Server is Amendment Blocked
|
||||
|
||||
One of the first signs that your `rippled` server is amendment blocked is an `amendmentBlocked` error that is returned when you submit a transaction. Here's an example `amendmentBlocked` error:
|
||||
|
||||
```json
|
||||
{
|
||||
"result":{
|
||||
"error":"amendmentBlocked",
|
||||
"error_code":14,
|
||||
"error_message":"Amendment blocked, need upgrade.",
|
||||
"request":{
|
||||
"command":"submit",
|
||||
"tx_blob":"479H0KQ4LUUXIHL48WCVN0C9VD7HWSX0MG1UPYNXK6PI9HLGBU2U10K3HPFJSROFEG5VD749WDPHWSHXXO72BOSY2G8TWUDOJNLRTR9LTT8PSOB9NNZ485EY2RD9D80FLDFRBVMP1RKMELILD7I922D6TBCAZK30CSV6KDEDUMYABE0XB9EH8C4LE98LMU91I9ZV2APETJD4AYFEN0VNMIT1XQ122Y2OOXO45GJ737HHM5XX88RY7CXHVWJ5JJ7NYW6T1EEBW9UE0NLB2497YBP9V1XVAEK8JJYVRVW0L03ZDXFY8BBHP6UBU7ZNR0JU9GJQPNHG0DK86S4LLYDN0BTCF4KWV2J4DEB6DAX4BDLNPT87MM75G70DFE9W0R6HRNWCH0X075WHAXPSH7S3CSNXPPA6PDO6UA1RCCZOVZ99H7968Q37HACMD8EZ8SU81V4KNRXM46N520S4FVZNSJHA"
|
||||
},
|
||||
"status":"error"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
The following `rippled` log message also indicates that your server is amendment blocked:
|
||||
|
||||
```
|
||||
2018-Feb-12 19:38:30 LedgerMaster:ERR One or more unsupported amendments activated: server blocked.
|
||||
```
|
||||
|
||||
You can verify that your `rippled` server is amendment blocked using the `server_info` command. In the response, look for `result.info.amendment_blocked`. If `amendment_blocked` is set to `true`, your server is amendment blocked.
|
||||
|
||||
**Example JSON-RPC Response:**
|
||||
|
||||
```json
|
||||
{
|
||||
"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"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
|
||||
## Unblock Servers
|
||||
|
||||
The easiest solution is to update to the latest version of `rippled`, but depending on the scenario, you may want to update to an older version with the amendment blocking your server.
|
||||
|
||||
**Warning:** If the newest `rippled` version provides security or other urgent fixes, you should upgrade to the newest version as soon as possible.
|
||||
|
||||
To determine if you can unblock your `rippled` server by upgrading to a version older than the newest version, find out which features are blocking your server and then look up the `rippled` version that supports the blocking features.
|
||||
|
||||
To find out which features are blocking your `rippled` server, use the [`feature`](feature.html) admin command. Look for features that have:
|
||||
|
||||
```
|
||||
"enabled" : true
|
||||
"supported" : false
|
||||
```
|
||||
|
||||
These values mean the amendment is required in the latest ledger, but your server doesn't support the implementation.
|
||||
|
||||
**Example JSON-RPC Response:**
|
||||
|
||||
```json
|
||||
{
|
||||
"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"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
In this example, conflicts with the following features are causing your `rippled` server to be amendment blocked:
|
||||
|
||||
* `157D2D480E006395B76F948E3E07A45A05FE10230D88A7993C71F97AE4B1F2D1`
|
||||
|
||||
* `67A34F2CF55BFC0F93AACD5B281413176FEE195269FA6D95219A2DF738671172`
|
||||
|
||||
* `F64E1EABBE79D55B3BB82020516CEC2C582A98A6BFE20FBE9BB6A0D233418064`
|
||||
|
||||
To look up which `rippled` version supports these features, see [Known Amendments](known-amendments.html).
|
||||
@@ -97,7 +97,7 @@ The following message indicates that the server has detected that it is running
|
||||
LedgerMaster:ERR Check for upgrade: A majority of trusted validators are running a newer version.
|
||||
```
|
||||
|
||||
This is not strictly a problem, but an old server version is likely to become [amendment blocked](amendments.html#amendment-blocked). You should [update `rippled`](install-rippled.html) to the latest stable version. (If you are connected to [devnet](parallel-networks.html), update to the latest nightly version instead.)
|
||||
This is not strictly a problem, but an old server version is likely to become [amendment blocked](amendments.html#amendment-blocked-servers). You should [update `rippled`](install-rippled.html) to the latest stable version. (If you are connected to [devnet](parallel-networks.html), update to the latest nightly version instead.)
|
||||
|
||||
|
||||
## Connection reset by peer
|
||||
|
||||
@@ -370,6 +370,11 @@ pages:
|
||||
targets:
|
||||
- ja
|
||||
|
||||
- md: privacy-policy.md
|
||||
targets:
|
||||
- en
|
||||
- ja
|
||||
|
||||
# Redirect old technical-faq.html to new faq.html URL
|
||||
- name: FAQ
|
||||
html: technical-faq.html
|
||||
@@ -1860,6 +1865,11 @@ pages:
|
||||
targets:
|
||||
- ja
|
||||
|
||||
- md: tutorials/manage-the-rippled-server/configuration/test-amendments.md
|
||||
targets:
|
||||
- en
|
||||
- ja
|
||||
|
||||
# TODO: translate this page & blurb
|
||||
- md: tutorials/manage-the-rippled-server/configuration/configure-statsd.md
|
||||
targets:
|
||||
@@ -2057,7 +2067,6 @@ pages:
|
||||
targets:
|
||||
- ja
|
||||
|
||||
# TODO: translate page and blurb
|
||||
- md: tutorials/manage-the-rippled-server/troubleshooting/health-check-interventions.md
|
||||
targets:
|
||||
- en
|
||||
@@ -2080,6 +2089,11 @@ pages:
|
||||
targets:
|
||||
- ja
|
||||
|
||||
- md: tutorials/manage-the-rippled-server/troubleshooting/server-is-amendment-blocked.md
|
||||
targets:
|
||||
- en
|
||||
- ja
|
||||
|
||||
- md: tutorials/manage-the-rippled-server/troubleshooting/server-wont-start.md
|
||||
targets:
|
||||
- en
|
||||
@@ -3695,6 +3709,10 @@ pages:
|
||||
- md: references/http-websocket-apis/peer-port-methods/health-check.md
|
||||
targets:
|
||||
- en
|
||||
|
||||
# TODO: translate page and blurb
|
||||
- md: references/http-websocket-apis/peer-port-methods/health-check.ja.md
|
||||
targets:
|
||||
- ja
|
||||
|
||||
- md: references/http-websocket-apis/peer-port-methods/peer-crawler.md
|
||||
|
||||
8
styles/_toml-checker.scss
Normal file
8
styles/_toml-checker.scss
Normal file
@@ -0,0 +1,8 @@
|
||||
.toml-checker {
|
||||
#result {
|
||||
display: none;
|
||||
}
|
||||
#verify-domain-result {
|
||||
display: none;
|
||||
}
|
||||
}
|
||||
@@ -445,6 +445,11 @@ aside .active > a:hover {
|
||||
white -2px -2px 3px, white -2px -2px 4px;
|
||||
}
|
||||
|
||||
// Osano cookie consent overrides
|
||||
a.osano-cm-link {
|
||||
color: #ffffff;
|
||||
}
|
||||
|
||||
// Layout elements -------------------------------------------------------------
|
||||
.card,
|
||||
.cta-card {
|
||||
|
||||
@@ -68,6 +68,7 @@ $line-height-base: 1.5;
|
||||
@import "_feedback.scss";
|
||||
@import "_video.scss";
|
||||
@import "_top-banner.scss";
|
||||
@import "_toml-checker.scss";
|
||||
|
||||
// Light/Dark theme settings ---------------------------------------------------
|
||||
// Option to only change theme on user system settings. No toggle.
|
||||
|
||||
@@ -20,7 +20,7 @@
|
||||
<div class="d-lg-flex row">
|
||||
<a href="{% if currentpage.prefix %}{{currentpage.prefix}}{% else %}/{% endif %}" class="footer-brand"><img src="{{currentpage.prefix}}assets/img/XRPLedger_DevPortal-white.svg" class="logo" height="24" alt="{{target.display_name}}" /></a>
|
||||
<span class="flex-grow-1"> </span>
|
||||
<div class="copyright-license">© 2021 XRP Ledger. <a href="https://raw.githubusercontent.com/XRPLF/xrpl-dev-portal/master/LICENSE">{% trans %}Open Source.{% endtrans %}</a>
|
||||
<div class="copyright-license">© 2023 XRP Ledger. <a href="https://raw.githubusercontent.com/XRPLF/xrpl-dev-portal/master/LICENSE">{% trans %}Open Source.{% endtrans %}</a>
|
||||
</div>
|
||||
</div><!-- /.absolute_bottom_footer -->
|
||||
|
||||
|
||||
18
template/page-privacy-policy.html.jinja
Normal file
18
template/page-privacy-policy.html.jinja
Normal file
@@ -0,0 +1,18 @@
|
||||
{% extends "pagetype-doc.html.jinja" %}
|
||||
{% block head %}
|
||||
|
||||
{% endblock %}
|
||||
|
||||
{% block bodyclasses %}page-privacy-policy{% endblock %}
|
||||
{% block breadcrumbs %}{% endblock %}
|
||||
|
||||
{% block analytics %}
|
||||
<script type="application/javascript">
|
||||
window.dataLayer = window.dataLayer || [];
|
||||
window.dataLayer.push({
|
||||
"event": "page_info",
|
||||
"page_type": "Splash Page",
|
||||
"page_group": "About"
|
||||
})
|
||||
</script>
|
||||
{% endblock analytics %}
|
||||
@@ -1,32 +1,59 @@
|
||||
{% extends "base.html.jinja" %}
|
||||
|
||||
{% block bodyclasses %}toml-checker{% endblock %}
|
||||
|
||||
{% block main %}
|
||||
<section class="container-fluid p-3">
|
||||
<h1>xrp-ledger.toml Checker</h1>
|
||||
<section class="container-fluid">
|
||||
<div class="p-3">
|
||||
<h1>xrp-ledger.toml Checker</h1>
|
||||
|
||||
<p>If you run an XRP Ledger validator or use the XRP Ledger for your business, you can provide information about your usage of the XRP Ledger to the world in a machine-readable <a href="https://developers.ripple.com/xrp-ledger-toml.html"><code>xrp-ledger.toml</code> file</a>.</p>
|
||||
<p>If you run an XRP Ledger validator or use the XRP Ledger for your business, you can provide information about your usage of the XRP Ledger to the world in a machine-readable <a href="https://xrpl.org/xrp-ledger-toml.html"><code>xrp-ledger.toml</code> file</a>.</p>
|
||||
|
||||
<p>This tool allows you to verify that your <code>xrp-ledger.toml</code> file is syntactically
|
||||
correct and deployed properly.</p><br/>
|
||||
<form id="domain-entry">
|
||||
<div class="input-group">
|
||||
<input id="domain" type="text" class="form-control" required
|
||||
placeholder="example.com (Domain name to check)"
|
||||
pattern="^([a-zA-Z0-9]([a-zA-Z0-9\-]{0,61}[a-zA-Z0-9])?\.)+[a-zA-Z][a-zA-Z-]{0,22}[a-zA-Z]$"><br>
|
||||
<button class="btn btn-primary form-control">Check toml file</button>
|
||||
</div><!--/.input-group-->
|
||||
</form>
|
||||
<div id="result">
|
||||
<h5 class='result-title'>Result</h5>
|
||||
<ul id="log">
|
||||
</ul>
|
||||
</div>
|
||||
|
||||
<div class="p-3 pb-5">
|
||||
<form id="domain-entry">
|
||||
<h4>Look Up By Domain</h4>
|
||||
<p>This tool allows you to verify that your <code>xrp-ledger.toml</code> file is syntactically
|
||||
correct and deployed properly.</p>
|
||||
<div class="input-group">
|
||||
<input id="domain" type="text" class="form-control" required
|
||||
placeholder="example.com (Domain name to check)"
|
||||
pattern="^([a-zA-Z0-9]([a-zA-Z0-9\-]{0,61}[a-zA-Z0-9])?\.)+[a-zA-Z][a-zA-Z-]{0,22}[a-zA-Z]$"><br>
|
||||
<button class="btn btn-primary form-control">Check toml file</button>
|
||||
</div><!--/.input-group-->
|
||||
</form>
|
||||
<div id="result">
|
||||
<h5 class='result-title'>Result</h5>
|
||||
<ul id="log">
|
||||
</ul>
|
||||
</div>
|
||||
</div>
|
||||
<div class="p-3 pt-5">
|
||||
<h4>Look Up By Account</h4>
|
||||
<p>Enter an XRP Ledger address to see if that account is claimed by the domain it says owns it.</p>
|
||||
<form id="domain-verification">
|
||||
<div class="input-group">
|
||||
<input id="verify-domain" type="text" class="form-control" required
|
||||
placeholder="r... (Wallet Address to check)">
|
||||
<br>
|
||||
<button class="btn btn-primary form-control">Check account</button>
|
||||
</div><!--/.input-group-->
|
||||
</form>
|
||||
<div id="verify-domain-result">
|
||||
<h5 id="verify-domain-result-title" class='result-title'>Result</h5>
|
||||
<ul id="verify-domain-log">
|
||||
</ul>
|
||||
</div>
|
||||
</div>
|
||||
</section>
|
||||
{% endblock %}
|
||||
|
||||
{% block endbody %}
|
||||
<script type="application/javascript" src="{{currentpage.prefix}}assets/vendor/iarna-toml-parse.js"></script>
|
||||
<script type="application/javascript" src="{{currentpage.prefix}}assets/js/xrp-ledger-toml-checker.js"></script>
|
||||
|
||||
<!-- TOML tool -->
|
||||
<script type="application/javascript" src="{{currentpage.prefix}}assets/vendor/iarna-toml-parse.js"></script>
|
||||
{% endblock %}
|
||||
|
||||
{% block analytics %}
|
||||
|
||||
Reference in New Issue
Block a user