understand the pre-requisit intro basics before diving into development on the Blockchain. references and info can be sourced here XRPL Concepts Page. contains all relevant Information to understanding the xrp ledger as well as building and deploying applications on the dlt.
contents
- why
- xrpl
- xrpl basics
- what is xrp
- what does xrp stand for
- what is iso 2022
- what is swift
- xrp ledger consensus protocol
- software ecosystem
- consensus research
- white paper
- send xrp
to secure internship at ripple xrpl internship
Analysis fo the XRP Ledger Consensus Protocol
The XRP Ledger Consensus Protocol is a previously developed consensus protocol powering the XRP Ledger. It is a low-latency Byzantine agreement protocol, capable of reaching consensus without full agreement on which nodes are members of the network. We present a detailed explanation of the algorithm and derive conditions for its safety and liveness.
We will be utilizing the
XRPLF/xrpl-dev-portalfor referencing documentation on XRPL
/**
* @file primitive.js
* @brief import the xrpl ledger, used to store
* all transactions and the state of the ledger
*/
const xrpl = require('xrpl');
console.log(xrpl);morgan% node primitive.js
{
BroadcastClient: [Getter],
Client: [Getter],
Wallet: [Getter],
keyToRFC1751Mnemonic: [Getter],
rfc1751MnemonicToKey: [Getter],
LedgerEntry: [Getter],
setTransactionFlagsToNumber: [Getter],
parseAccountRootFlags: [Getter],
validate: [Getter],
AccountSetAsfFlags: [Getter],
AccountSetTfFlags: [Getter],
NFTokenCreateOfferFlags: [Getter],
NFTokenMintFlags: [Getter],
OfferCreateFlags: [Getter],
PaymentFlags: [Getter],
PaymentChannelClaimFlags: [Getter],
TrustSetFlags: [Getter],
getBalanceChanges: [Getter],
dropsToXrp: [Getter],
xrpToDrops: [Getter],
hasNextPage: [Getter],
rippleTimeToISOTime: [Getter],
isoTimeToRippleTime: [Getter],
rippleTimeToUnixTime: [Getter],
unixTimeToRippleTime: [Getter],
percentToQuality: [Getter],
decimalToQuality: [Getter],
percentToTransferRate: [Getter],
decimalToTransferRate: [Getter],
transferRateToDecimal: [Getter],
qualityToDecimal: [Getter],
isValidSecret: [Getter],
isValidAddress: [Getter],
hashes: [Getter],
deriveKeypair: [Getter],
deriveAddress: [Getter],
deriveXAddress: [Getter],
signPaymentChannelClaim: [Getter],
verifyKeypairSignature: [Getter],
verifyPaymentChannelClaim: [Getter],
convertStringToHex: [Getter],
convertHexToString: [Getter],
classicAddressToXAddress: [Getter],
xAddressToClassicAddress: [Getter],
isValidXAddress: [Getter],
isValidClassicAddress: [Getter],
encodeSeed: [Getter],
decodeSeed: [Getter],
encodeAccountID: [Getter],
decodeAccountID: [Getter],
encodeNodePublic: [Getter],
decodeNodePublic: [Getter],
encodeAccountPublic: [Getter],
decodeAccountPublic: [Getter],
encodeXAddress: [Getter],
decodeXAddress: [Getter],
encode: [Getter],
decode: [Getter],
encodeForMultiSigning: [Getter],
encodeForSigning: [Getter],
encodeForSigningClaim: [Getter],
createCrossChainPayment: [Getter],
parseNFTokenID: [Getter],
XrplError: [Getter],
UnexpectedError: [Getter],
ConnectionError: [Getter],
RippledError: [Getter],
NotConnectedError: [Getter],
DisconnectedError: [Getter],
RippledNotInitializedError: [Getter],
TimeoutError: [Getter],
ResponseFormatError: [Getter],
ValidationError: [Getter],
NotFoundError: [Getter],
XRPLFaucetError: [Getter],
authorizeChannel: [Getter],
verifySignature: [Getter],
multisign: [Getter]
}/**
* @file primitive.js
* @brief This file is a simple
* example of how to use the xrpl.js library
* @param: none
* @return: none
*/
// import the xrpl ledger this is the ledger that is used to store all the transactions and the state of the ledger, require is a function that is used to import a module
const xrpl = require('xrpl');
async function main() {
// this is the address of the account that we are going to use in order to send a transaction
/**
* @brief client is
* @param: server at address
* wws://s.altnet.rippletest.net:51233
*/
const client = new xrpl.Client("wss://s.altnet.rippletest.net:51233");
/**
* client.connect() is a promise that resolves when
* the connection is established
*/
await client.connect();
// response is an object that contains the information about the account
// client.request is a function that is used to send a request to the server
// paratemers of the request are the command and the account addresss
const response = await client.request({
// command is the command that we are going to send to the server
"command": "account_info",
// account is a alphanumeric string that is the address of the account
"account": "rPT1Sjq2YGrBMTttX4GZHjKu9dyfzbpAYe",
// "validated" is a boolean that is used to specify if we want to get the information from the validated ledger or from the current ledger
"ledger_index": "validated"
});
// print the response
console.log(response);
// disconnect from the server
client.disconnect()
}
main()
X prefix for non-national currencies in the ISO 4217 standard.
XRPL (XRP Ledger) is a Distributed Ledger Technology, is a decentralized, public blockchain led by a global developer community. The ledger is owned by Ripple Labs Inc. XRP is a Internationally recognized standarized asset/currency code validated and now compliant by ISO 20022 - ISO 2022 is under SWIFT known to be the Society for Worldwide Interbank Financial Telecommunications which provides a secure messaging system for financial transactions between participating banks. A Currency Code is a code allocated to a currency by a Maintenance Agency under an international identification scheme as described in the latest edition of the international standard ISO "Codes for the representation of currencies and funds".
XRP is the three-letter currency/asset code formed by appending a single character to a two-letter county code of the issuing country.
X - Asset
RP - Ripple Labs
The X Represents assets not issued by any country, via standarizations XRP is not issued by any country, thus for assets not issued by any country, the first letter must be X. No country codes starting with X will be issued. So, for example, since the chemical symbol for gold is Au, gold’s currency code is XAU. XRP’s first letter is X because XRP is not issued by any country. In the early days, we called the ledger’s native asset “ripples”. So the natural currency code to choose was “XRP”.
Examples
-
USD - United States "Dollar"
Since the United States’ country code is “US”, US dollars have the currency code “USD”.
-
EUR - European Union "Euro"
The European Union is a not a country, but still acts as a country code. The EU has the country code “EU”, so the currency code for Euros is “EUR”.
-
XBT - Bitcoin "Asset"
Some people use “BTC” for bitcoin, however the formalization standard of bitcoin is actually “XBT”.
ISO2022 - Universal Financial Industry Message Scheme
ISO20022 International Organization for Standardization is a single standarization approach (methodology, process, repository) to be used by all financial standards initiatives. It is a standard/protocol that allows for electronic data to interchange between different financial institutions. In covers financial information transferred between organizations that include credit or debit card transactions, settlement data and securities trading, and other payment transactions. In general the payment protocols and messages across the world are validated by countries and financial networks which all adhere to various standardizations. These standardizations are recognized by the IS) 20022 which bring legacy payment infrastructure to help global interoperabilityy and allow for world's cross-border payment flows. RippleNet is apart of the ISO 20022 Registrtaion Management Group (RMG) standards body and the first member focused on Distributed Ledger Technology (DTL).
Swift is the global providor of secure financial messaging services and implements cross-border payment systems such as ISO 2022
The XRP Ledger Consensus Protocol is a previously developed consensus protocol powering the XRP Ledger. It is a low-latency Byzantine agreement protocol, capable of reaching consensus without full agreement on which nodes are members of the network. We present a detailed explanation of the algorithm and derive conditions for its safety and liveness.
Before we establish what the XRP Ledger Consensus Protocol is we need to first establish a basic understand on what a communication/network protocol is. A protocol is a system of rules that allows two or more communications systems to transmit infomation/data via any kind of variation of a physical quantity. The protocol defines a set of rules, syntax, semantics, synchronization ... of communication and possible error recovery methods. Protocols in our case for the Consensus for XRP blockchain will be implemented by software.
Consensus is the most important property of any decentralized payment system. In traditional centralized payment systems, one authoritative administrator gets the final say in how and when payments occur. Decentralized systems, by definition, don't have an administrator to do that. Instead, decentralized systems like the XRP Ledger define a set of rules all participants follow, so every participant can agree on the exact same series of events and their outcome at any point in time. We call this set of rules a consensus protocol.
Consensus protocols are a solution to the double-spend problem: the challenge of preventing someone from successfully spending the same digital money twice. The hardest part about this problem is putting transactions in order: without a central authority, it can be difficult to resolve disputes about which transaction comes first when you have two or more mutually-exclusive transactions sent around the same time. For a detailed analysis of the double-spend problem, how the XRP Ledger Consensus Protocol solves this problem, and the tradeoffs and limitations involved, see Consensus Principles and Rules.
The XRP Ledger uses a consensus protocol unlike any digital asset that came before it. This protocol, known as the XRP Ledger Consensus Protocol, is designed to have the following important properties:
Current Centralized Payment Systems are parties exchanging with an intermediary that being in this fragmented 3 Finite Automata. Where behavior of exchnage depends on the intermediary (The Bank) to validate transactions.
-
Everyone who uses the XRP Ledger can agree on the latest state, and which transactions have occurred in which order. All valid transactions are processed without needing a central operator or having a single point of failure.
-
All valid transactions are processed without needing a central operator or having a single point of failure.
-
The ledger can make new blocks even if some participants join, leave, or behave inappropriately.
-
The confimration of transactions is not a is a consensus mechanism which doe snot require any Proof of Work mining unlike other blockchain systems.
An XRP ledger processes transactions in blocks called "ledger versions". Each ledger version contains three pieces:
ledger version contents
-
The current state of all balances and objects stored in the ledger.
-
The set of transactions that have been applied to the previous ledger to result in this one.
-
Metadata about the current ledger version
ledger index cyrptographic hash
that uniquely identifies its contents, and information about the parent ledger that was used as a basis for building one like such. The following is an example of a ledger version comprising of metadata, states, and transactions.
genesis ledger with ledger index 1 ->
Analysis fo the XRP Ledger Consensus Protocol
Add post script file here
The XRP Ledger Consensus Protocol is a previously developed consensus protocol powering the XRP Ledger. It is a low-latency Byzantine agreement protocol, capable of reaching consensus without full agreement on which nodes are members of the network. We present a detailed explanation of the algorithm and derive conditions for its safety and liveness.
