ARCHIVE/xahaud
3
0
Fork 0
mirror of https://github.com/Xahau/xahaud.git synced 2025-11-19 18:15:50 +00:00
Code Issues Packages Projects Releases Wiki Activity

Remove obsolete URLs and references to Ripple

Browse Source
This commit is contained in:
Crypto Brad Garlinghouse
2021-03-12 15:14:54 +03:00
committed by manojsdoshi
parent 6d82fb83a0
commit cf8438fe1d
14 changed files with 22 additions and 375 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
docs/consensus.md
View File

@@ -4,7 +4,7 @@
Consensus is the task of reaching agreement within a distributed system in the
presence of faulty or even malicious participants. This document outlines the
[Ripple Consensus Algorithm](https://ripple.com/files/ripple/consensus/whitepaper.pdf)
[XRP Ledger Consensus Algorithm](https://arxiv.org/abs/1802.07242)
as implemented in [rippled](https://github.com/ripple/rippled), but
focuses on its utility as a generic consensus algorithm independent of the
detailed mechanics of the Ripple Consensus Ledger. Most notably, the algorithm

12
src/ripple/app/misc/FeeEscalation.md
View File

@@ -188,9 +188,9 @@ lower) fee to get into the same position as a reference transaction.
For consensus to be considered healthy, the consensus process must take
less than 5 seconds. This time limit was chosen based on observed past
behavior of the ripple network. Note that this is not necessarily the
time between ledger closings, as consensus usually starts some amount
of time after a ledger opens.
behavior of the network. Note that this is not necessarily the time between
ledger closings, as consensus usually starts some amount of time after
a ledger opens.
### Other Constants
@@ -213,7 +213,7 @@ than what the default would allow. This exact value was chosen
experimentally, and can easily change in the future.
* *Transaction queue size limit*. The limit is computed based on the
base fee transaction limit per ledger, so that the queue can grow
automatically as the ripple network's performance improves, allowing
automatically as the network's performance improves, allowing
more transactions per second, and thus more transactions per ledger
to process successfully. The limit of 20 ledgers was used to provide
a balance between resource (specifically memory) usage, and giving
@@ -291,7 +291,7 @@ Result format:
}
```
### [`server_info`](https://ripple.com/build/rippled-apis/#server-info) command
### [`server_info`](https://xrpl.org/server_info.html) command
**The fields listed here are still experimental, and may change
without warning.**
@@ -313,7 +313,7 @@ need to overcome `load_factor_fee_escalation`, though if it does not, it
is more likely to be queued than immediately processed into the open
ledger.
### [`server_state`](https://ripple.com/build/rippled-apis/#server-state) command
### [`server_state`](https://xrpl.org/server_state.html) command
**The fields listed here are still experimental, and may change
without warning.**

3
src/ripple/app/paths/Pathfinder.cpp
View File

@@ -444,8 +444,7 @@ Pathfinder::computePathRanks(int maxPaths)
static bool
isDefaultPath(STPath const& path)
{
// TODO(tom): default paths can consist of more than just an account:
// https://forum.ripple.com/viewtopic.php?f=2&t=8206&start=10#p57713
// FIXME: default paths can consist of more than just an account:
//
// JoelKatz writes:
// So the test for whether a path is a default path is incorrect. I'm not

137
src/ripple/app/paths/README.md
View File

@@ -1,137 +0,0 @@
Theory of Pathfinding
=====================
It's a hard problem - an exponential problem - and there is a limited amount of time until the ledger changes.
Search for the best path, but it's impossible to guarantee the result is the best unless the ledger is small.
Also, the current state of the ledger can't be definitively known. We only know the state of past ledgers.
By the time a transaction is processed, liquidity may be taken or added. This is why payments support a maximum cost.
People are given estimates so they can make a decision as to whether the overall cost is good enough for them.
This is the **rippled** implementation; there are many other possible implementations!
**rippled** uses a variety of search techniques:
1. Hebbian learning.
* Reuse found liquidity.
* Good liquidity is often reusable.
* When searching, limit our search to the rippled cache.
2. Six degrees of separation.
* If sending value through individual's account, expect no path to have more than six hops.
* According to [Facebook studies](https://www.facebook.com/notes/facebook-data-team/anatomy-of-facebook/10150388519243859) as of late 2011, its users are separated by fewer than five steps.
* By using XRP for bridging the most complicated path expected is usually:
* source -> gateway -> XRP -> gateway -> destination
3. Pareto principle.
* Good liquidity is often reusable.
* Concentrate on the most liquid gateways to serve almost everybody.
* People who chose to use illiquid gateways get the service level implied by their choice of poor liquidity.
4. Monte Carlo methods.
* Learn new paths.
* Search outside the **rippled** cache.
* Distributed learning.
* Every rippled node searches their own cache for best liquidity and then the good results get propagated to the network.
* Whenever somebody makes a payment, the nodes involved go to the rippled cache; since payments appear in every ledger in the network, this liquidity information now appears in every rippled cache.
Life of a Payment
======================
Overview
----------
Making a payment in the ripple network is about finding the cheapest path between source and destination.
There are various stages:
An issue is a balance in some specific currency. An issuer is someone who "creates" a currency by creating an issue.
For tx processing, people submit a tx to a rippled node, which attempts to apply the tx locally first, and if succeesful, distributes it to other nodes.
When someone accepts payment they list their specific payment terms, "what must happen before the payment goes off." That can be done completely in the Ripple Network. Normally a payment on the Ripple net can be completely settled there. When the ledger closes, the terms are met, or they are not met.
For a bridge payment, based on a previous promise it will deliver payment off-network. A bridge promises to execute the final leg of a payment, but there's the possibility of default. If you want to trust a bridge for a specific pathfinding request, you need to include it in the request.
In contrast, a gateway is in the business of redeeming value on the Ripple Network for value off the Ripnet. A gateway is in the business of issuing balances.
Bitstamp is a gateway - you send 'em cash, they give you a ripple balance and vice versa. There's no promise or forwarding for a transaction.
A bridge is a facility that allows payments to be made from the Ripnet to off the Ripnet.
Suppose I'm on the Ripple network and want to send value to the bitcoin network. See: https://ripple.com/wiki/Outbound_Bridge_Payments
https://ripple.com/wiki/Services_API
Two types of paths:
1. I have X amount of cash I wish to send to someone - how much will they receive?
* not yet implemented in pathfinding, or at least in the RPC API.
* TODO: find if this is implemented and either document it or file a JIRA.
2. I need to deliver X amount of cash to someone - how much will it cost me?
Here's a transaction:
https://ripple.com/wiki/Transaction_Format#Payment_.280.29
Not implemented: bridge types.
High level of a payment
-----------------------
1. I make a request for path finding to a rippled.
2. That rippled "continuously" returns solutions until I "stop".
3. You create a transaction which includes the path set that you got from the quote.
4. You sign it.
5. You submit it to one or more rippleds.
6. Those rippled validates it, and forwards it if it;s valid.
* valid means "not malformed" and "can claim a fee" - the sending account has enough to cover the transaction fee.
7. At ledger closing time, the transaction is applied by the transaction engine and the result is stored by changing the ledger and storing the tx metadata in that ledger.
If you're sending and receiving XRP you don't need a path.
If the union of the default paths are sufficient, you don't need a path set (see below about default paths).
The idea behind path sets is to provide sufficient liquidity in the face of a changing ledger.
If you can compute a path already yourself or know one, you don't need to do steps 1 or 2.
1. Finding liquidity - "path finding"
* finding paths (exactly "path finding")
* filtering by liquidity.
* take a selection of paths that should satisfy the transaction's conditions.
* This routine is called RippleCalc::rippleCalc.
2. Build a payment transaction containing the path set.
* a path set is a group of paths that a transaction is supposed to use for liquidity
* default paths are not included
* zero hop path: a default path is "source directly to destination".
* one hop paths - because they can be derived from the source and destination currency.
* A payment transaction includes the following fields
* the source account
* the destination account
* destination amount
* contains an amount and a currency
* if currency not XRP, must have a specified issuer.
* If you specify an issuer then you MUST deliver that issuance to the destination.
* If you specify the issuer as the destination account, then they will receive any of the issuances they trust.
* maximum source amount - maximum amount to debit the sender.
* This field is optional.
* if not specified, defaults to the destination amount with the sender as issuer.
* contains an amount and a currency
* if currency not XRP, must have a specified issuer.
* specifying the sender as issuer allows any of the sender's issuance to be spent.
* specifying a specific issuer allows only that specific issuance to be sent.
* path set.
* Optional.
* Might contain "invalid" paths or even "gibberish" for an untrusted server.
* An untrusted server could provide proof that their paths are actually valid.
* That would NOT prove that this is the cheapest path.
* The client needs to talk to multiple untrusted servers, get proofs and then pick the best path.
* It's much easier to validate a proof of a path than to find one, because you need a lot of information to find one.
* In the future we might allow one server to validate a path offered by another server.
3. Executing a payment
* very little time, can't afford to do a search.
* that's why we do the path building before the payment is due.
* The routine used to compute liquidity and ledger change is also called RippleCalc::rippleCalc.

211
src/ripple/app/tx/README.md
View File

@@ -1,211 +0,0 @@
# Transactors #
## Introduction ##
Each separate kind of transaction is handled by it's own Transactor.
The Transactor base class provides functionality that is common to
all derived Transactors. The Transactor base class also gives derived
classes the ability to replace portions of the default implementation.
# Details on Specific Transactors #
## AddWallet ##
## Change ##
## Offers ##
### CreateOffer ###
### CancelOffer ###
## Payment ##
## SetAccount ##
## SetRegularKey ##
## SetSignerList ##
In order to enhance the flexibility of Ripple and provide support for enhanced
security of accounts, native support for "multi-signature" or "multi-sign"
accounts is required.
Transactions on an account which is designated as multi-sign can be authorized
either by using the master or regular keys (unless those are disabled) or by
being signed by a certain number (a quorum) of pre-authorized accounts.
Some technical details, including tables indicating some of the Ripple
commands and ledger entries to be used for implementing multi-signature, are
currently listed on the [wiki](https://ripple.com/wiki/Multisign) but will
eventually be migrated into this document as well.
For accounts which are designated as multi-sign, there must be a list which
specifies which accounts are authorized to sign and the quorum threshold.
- Each authorized account has a weight. The sum of the weights of the signers is used to determine whether a given set of signatures is sufficient for a quorum.
- The quorum threshold indicates the minimum required weight that the sum of the weights of all signatures must have before a transaction can be authorized.
### Verification of Multiple Signatures During TX Processing
The current approach to adding multi-signature support is to require that a
transaction is to be signed outside the Ripple network and only submitted
after the quorum has been reached.
This reduces the implementation footprint and the load imposed on the network,
and mirrors the way transaction signing is currently handled. It will require
some messaging mechanism outside the Ripple network to disseminate the proposed
transaction to the authorized signers and to allow them to apply signatures.
Supporting in-ledger voting should be considered, but it has both advantages
and disadvantages.
One of the advantages is increased transparency - transactions are visible as
are the "votes" (the authorized accounts signing the transaction) on the
ledger. However, transactions may also languish for a long time in the ledger,
never reaching a quorum and consuming network resources.
### Signature Format
We should not develop a new format for multi-sign signatures. Instead every
signer should extract and sign the transaction as they normally would if this
were a regular transaction. The resulting signature will be stored as a triple
of { signing-account, signer-public-key, signature } in an array of signatures
associated with this transaction.
The advantage of this is that we can reuse the existing signing and
verification code, and leverage the work that will go towards implementing
support for the Ed25519 elliptic curve.
### Fees ###
Multi-signature transactions impose a heavier load on the network and should
claim higher fees.
The fee structure is not yet decided, but an escalating fee structure is laid
out and discussed on the [wiki](https://ripple.com/wiki/Multisign). This
might need to be revisited and designed in light of discussions about changing
how fees are handled.
### Proposed Transaction Cancellation ###
A transaction that has been proposed against a multi-sign account using a
ticket can be positively canceled if a quorum of authorized signers sign and
issue a transaction that consumes that ticket.
### Implementation ###
Any account can have one SignerList attached to it. A SignerList contains the
following elements:
- A list of from 1 to a protocol-defined maximum of 8 signers. Each signer in the array consists of:
- The signer's 160-bit account ID and
- The signer's 16-bit weight (used to calculate whether a quorum is met).
- And, for the entire list, a single 32-bit quorum value.
Giving the signers different weights allows an account to organize signers so
some are more important than others. A signer with a larger weight has more
significance in achieving the quorum.
A multi-signed transaction is validated like this:
- Each signer of the transaction has their signature validated.
- The weights of all valid signers are summed.
- If the sum of the weights equals or exceeds the quorum value then the entire transaction is considered signed. If the sum is below the quorum, then the signature fails with a tefBAD_QUORUM.
By making the signer weights 16 bits and the quorum value 32 bits we avoid
concerns about overflows and still have plenty of resolution.
This transactor allows two operations:
- Create (or replace) a signer list for the target account.
- Remove any signer list from the target account.
The data for a transaction creating or replacing a signer list has this
general form:
{
"TransactionType": "SignerListSet",
"Account": "rDg53Haik2475DJx8bjMDSDPj4VX7htaMd",
"SignerQuorum": 7,
"SignerEntries": [
{
"SignerEntry": {
"Account": "rnUy2SHTrB9DubsPmkJZUXTf5FcNDGrYEA",
"SignerWeight": 4
}
},
{
"SignerEntry": {
"Account": "rPcNzota6B8YBokhYtcTNqQVCngtbnWfux",
"SignerWeight": 3
}
}
]
}
The data for a transaction that removes any signer list has this form:
{
"TransactionType": "SignerListSet",
"Account": "rDg53Haik2475DJx8bjMDSDPj4VX7htaMd",
"SignerQuorum": 0
}
## SetTrust ##
## Tickets ##
Currently transactions on the Ripple network require the use of sequence
numbers and sequence numbers must monotonically increase. Since the sequence
number is part of the transaction, it is "covered" by the signature that
authorizes the transaction, which means that the sequence number would have
to be decided at the time of transaction issuance. This would mean that
multi-signature transactions could only be processed in strict "first-in,
first-out" order which is not practical.
Tickets can be used in lieu of sequence number. A ticket is a special token
which, through a transaction, can be issued by any account and can be
configured with an optional expiry date and an optional associated account.
### Specifics ###
The expiry date can be used to constrain the validity of the ticket. If
specified, the ticket will be considered invalid and unusable if the closing
time of the last *validated* ledger is greater than or equal to the expiration
time of the ticket.
The associated account can be used to specify an account, other than the
issuing account, that is allowed to "consume" the ticket. Consuming a ticket
means to use the ticket in a transaction that is accepted by the network and
makes its way into a validated ledger. If not present, the ticket can only be
consumed by the issuing account.
*Corner Case:* It is possible that two or more transactions reference the same
ticket and that both go into the same consensus set. During final application
of transactions from the consensus set at most one of these transactions may
succeed; others must fail with the indication that the ticket has been consumed.
*Reserve:* While a ticket is outstanding, it should count against the reserve
of the *issuer*.
##### Issuance
We should decide whether, in the case of multi-signature accounts, any single
authorized signer can issue a ticket on the multi-signature accounts' behalf.
This approach has both advantages and disadvantages.
Advantages include:
+ Simpler logic for tickets and reduced data - no need to store or consider an associated account.
+ Owner reserves for issued tickets count against the multi-signature account instead of the account of the signer proposing a transaction.
+ Cleaner meta-data: easier to follow who issued a ticket and how many tickets are outstanding and associated with a particular account.
Disadvantages are:
+ Any single authorized signer can issue multiple tickets, each counting against the account's reserve.
+ Special-case logic for authorizing tickets on multi-sign accounts.
I believe that the disadvantages outweigh the advantages, but debate is welcome.
### CreateTicket ###

8
src/ripple/app/tx/impl/Escrow.cpp
View File

@@ -58,22 +58,22 @@ namespace ripple {
expiration time, the XRP can only be returned to the sender.
For more details on escrow, including examples, diagrams and more please
visit https://ripple.com/build/escrow/#escrow
visit https://xrpl.org/escrow.html
For details on specific transactions, including fields and validation rules
please see:
`EscrowCreate`
--------------
See: https://ripple.com/build/transactions/#escrowcreate
See: https://xrpl.org/escrowcreate.html
`EscrowFinish`
--------------
See: https://ripple.com/build/transactions/#escrowfinish
See: https://xrpl.org/escrowfinish.html
`EscrowCancel`
--------------
See: https://ripple.com/build/transactions/#escrowcancel
See: https://xrpl.org/escrowcancel.html
*/
//------------------------------------------------------------------------------

2
src/ripple/app/tx/impl/Payment.cpp
View File

@@ -28,8 +28,6 @@
namespace ripple {
// See https://ripple.com/wiki/Transaction_Format#Payment_.280.29
TxConsequences
Payment::makeTxConsequences(PreflightContext const& ctx)
{

2
src/ripple/app/tx/impl/Payment.h
View File

@@ -27,8 +27,6 @@
namespace ripple {
// See https://ripple.com/wiki/Transaction_Format#Payment_.280.29
class Payment : public Transactor
{
/* The largest number of paths we allow */

2
src/ripple/basics/chrono.h
View File

@@ -40,7 +40,7 @@ using days = std::chrono::duration<
using weeks = std::chrono::
duration<int, std::ratio_multiply<days::period, std::ratio<7>>>;
/** Clock for measuring Ripple Network Time.
/** Clock for measuring the network time.
The epoch is January 1, 2000
epoch_offset = days(10957); // 2000-01-01

6
src/ripple/net/ShardDownloader.md
View File

@@ -208,9 +208,9 @@ used instead.
```dosini
# This is the persistent datastore for shards. It is important for the health
# of the ripple network that rippled operators shard as much as practical.
# NuDB requires SSD storage. Helpful information can be found here
# https://ripple.com/build/history-sharding
# of the network that rippled operators shard as much as practical.
# NuDB requires SSD storage. Helpful information can be found on
# https://xrpl.org/history-sharding.html
[shard_db]
type=NuDB
path=/var/lib/rippled/db/shards/nudb

6
src/ripple/nodestore/README.md
View File

@@ -275,9 +275,9 @@ and several paths for historical storage:
```dosini
# This is the persistent datastore for shards. It is important for the health
# of the ripple network that rippled operators shard as much as practical.
# NuDB requires SSD storage. Helpful information can be found here
# https://ripple.com/build/history-sharding
# of the network that server operators shard as much as practical.
# NuDB requires SSD storage. Helpful information can be found on
# https://xrpl.org/history-sharding.html
[shard_db]
type=NuDB

2
src/ripple/protocol/impl/PublicKey.cpp
View File

@@ -106,7 +106,7 @@ sliceToHex(Slice const& slice)
@param strict_param whether to enforce strictly canonical semantics
@note For more details please see:
https://ripple.com/wiki/Transaction_Malleability
https://xrpl.org/transaction-malleability.html
https://bitcointalk.org/index.php?topic=8392.msg127623#msg127623
https://github.com/sipa/bitcoin/commit/58bc86e37fda1aec270bccb3df6c20fbd2a6591c
*/

2
src/test/core/Config_test.cpp
View File

@@ -68,7 +68,7 @@ medium
# This is primary persistent datastore for rippled. This includes transaction
# metadata, account states, and ledger headers. Helpful information can be
# found here: https://ripple.com/wiki/NodeBackEnd
# found on https://xrpl.org/capacity-planning.html#node-db-type
# delete old ledgers while maintaining at least 2000. Do not require an
# external administrative command to initiate deletion.
[node_db]

2
src/test/jtx/Env.h
View File

@@ -254,7 +254,7 @@ public:
return *bundle_.timeKeeper;
}
/** Returns the current Ripple Network Time
/** Returns the current network time
@note This is manually advanced when ledgers
close or by callers.