DEV Community: Marlon

XRPL: Console log the ledger index

Marlon — Sun, 15 Sep 2024 03:08:19 +0000

Tools needed:

Node.js
NPM
VS Code

Create a new repository, initialize NPM, and install the XRPL.js package:

mkdir helloWorld
cd helloWorld
npm init
npm i xrpl

Create a new app.js file in the repository:

touch app.js

Open the file and paste this code into it:

// Pull the XRPL package into the file
const XRPL = require('xrpl');

// Create an async function to console log of the ledger index
const displayLastLedgerIndex = async () => {
  // Connect to the XRPL client via a desired network
  const client = new XRPL.Client('wss://xrplcluster.com');
  await client.connect();

  // Request XRPL client information
  const ledgerInfo = await client.request({
    command: 'ledger',
    ledger_index: 'validated',
  });

  // Console log the ledger index
  console.log(`Hello World, from the XRPL. The last index was: ${ledgerInfo.result.ledger_index}`);

  // Disconnect from the XRPL client
  await client.disconnect();
};

// Call the async function
displayLastLedgerIndex();

Now, run this code:

node app.js

There you have it! We've both made our step in interacting with the XRPL. Please like and share if you found this information valuable.

Stellar Blockchain (XLM): Configuration Options

Marlon — Sat, 26 Nov 2022 02:40:40 +0000

Configuration Options

There are five main configuration options that are relevant as of now, and these are Account Merge, Manage Data, Set Options - Home Domain, Set Options - Weight, Thresholds, and Signers, and SetFlags.

Account Merge

An Account Merge operation is used when you want to delete an account on the Stellar blockchain. In order to delete an account, you must get rid of all your native XLM and subentries; such as trustlines, additional signers, open offers, and data entries.

Manage Data

The Manage Data operation consists of setting, modifying, or deleting data entries within an account’s metadata. Data entries are a key/value pair of application-specific data attached to an account. Each data entry increases the account’s minimum balance by one base reserve- 0.5 XLM.

Set Options: Home Domain

The Set Options operation enables many different configurations. The Home Domain configuration option allows an individual account to point to a web browser domain. The domain serves a TOML file that displays information about the account's Stellar integration. The stellar.toml file proves who owns the HTTPS domain linked to a Stellar account, and that the owner is responsible for accounts and assets linked on it.

Set Options - Weights, Thresholds, and Signers

Again, the Set Options operation enables many different configurations. The weights, thresholds, and signers configuration options allows an account to set weights for the master key and additional signers, set thresholds for operations, and add additional signers to an account for multi-signature transactions. The weight of a signer determines how much leverage the signer has in each transaction, and the default weight for the master key is one. Each operation is categorized as having either a low, medium, or high threshold (0-255), and the default threshold value for each category is zero; which guarantees that the master key can always sign the transaction. If the thresholds are set to be greater than zero, then the master key's plus additional signers weights need to be greater than the operation threshold. It's possible to lock yourself out of your account if the operation thresholds are set to be greater than the signature weights added up together.

Set Options: Set Flags; Set Trust Line Flags

Again, the Set Options operation enables many different configurations. There are four flags that can be set: Authorized Required, Authorization Revocable, Authorization Immutable_, and Clawback Enabled. The authorized required flag will require another account to be approved before it can hold the issued asset. The authorization revocable flag will enable the issuing account to revoke another account from being authorized; which prevents the other account from transferring or trading the asset, and closes any open orders. The authorization immutable flag restricts any of the other flags from being set and disables the issuing account from being mergeable. The clawback enabled flag gives the issuing account the right to get back any portion of the other account's balance of the issued asset. When interacting with issued assets, it's important to know which flags they have set so you're not caught off guard by revoked or clawbacked assets.

The Set Trust Line Flags operation enables the issuing account to set flags for individual trustlines. There are two flags that can be set for this operation: Authorized and Authorized To Maintain Liabilities. The authorized flag gives full authorization to another account (truster) allowing it to transact freely with the issued asset. The authorized to maintain liabilities flag gives limited authorization allowing it to maintain current orders, but prevents future operations from occurring without approval.

Outro

I plan on writing corresponding blog posts with relevant code examples. For now, I am simply learning the basics of the Stellar blockchain and utilizing the Stellar Laboratory in order to interact with the test net.

If you wish to learn about the Stellar blockchain, and earn while doing it, then please visit: https://quest.stellar.org/

Stellar (XLM) Blockchain: Account Merge

Marlon — Wed, 02 Nov 2022 17:52:05 +0000

What is an Account Merge?

An account merge, on the Stellar (XLM) Blockchain, is the operation for deleting an account. The account is deleted and removed from the ledger when all of its XLM (Lumens), including the base reserves, are transferred to another account.

Before this operation may be carried out successfully, all subentries like trustlines, additional signers, open offers, and data entries must be removed.

Side Comment

You may notice this blog post is shorter than my previous Stellar Quests posts. I'm changing up the format of these posts by only summarizing the WHAT and not the HOW. That'll be much more relevant when I begin to use the Stellar SDK (Software Development Kit).

I plan on writing corresponding blog posts with relevant code examples. For now, I'm simply learning the basics of the Stellar blockchain and utilizing the Stellar Laboratory in order to interact with the test net. If you wish to learn about the Stellar blockchain, and earn while doing it, then please visit: https://quest.stellar.org/

Stellar Quests Level 1: Guide

Marlon — Thu, 27 Oct 2022 19:08:26 +0000

Quests L1

Level 1, in the Stellar Quests, was all about Payment Operations. These operations were: Create Account, Payment, Change Trust, Manage Offers, and Path Payments. We are guided through each of these in this order, and each step takes us further into the Stellar galaxy. Let's briefly overview each payment operation.

Create Account

This operation allows one to instantiate an account on the Stellar network. We can either instantiate the account with a starting amount of 0 or more. The base reserve for an account to exist is 1 Lumen ($XLM).

Learn more here: https://dev.to/gldnwzrd/stellar-quests-level-1-create-account-276g

Payment

This operation allows one to send the native asset Lumen ($XLM), or a custom asset directly to a destination account on the Stellar network. The amount sent must be greater than 0, and cannot cause the account to go below its reserve minimum.

Learn more here: https://dev.to/gldnwzrd/stellar-quests-level-1-payment-57lm

Change Trust

This operation allows one to establish a trustline with the issuer account, of a custom asset, on the Stellar network. One can set a limit on the amount their willing to trust. Calling this operation again, after getting rid of the entire balance of the custom asset, with the amount their willing to trust at 0 will remove the trustline entirely.

Learn more here: https://dev.to/gldnwzrd/stellar-quests-level-1-change-trust-5hhf

Manage Offers

This operation allows one to make an exchange between two assets on the Stellar network's native decentralized exchange. There are three operations under this belt: Manage Buy Offer, Manage Sell Offer, and Passive Buy Offer. All offers require that you sell one asset for another, but are different based on functionality or intention. In both Manage Buy and Sell Offers, we are putting up X amount of an asset for X amount of another asset; this operation executes immediately. Passive Buy Offer is unique in that it doesn't execute immediately on existing offers in the DEX (decentralized exchange); instead, it waits for new buy or sell offers. Side note, Passive Offers may be used to create a stable balance (zero spread) between two equal assets, and thus are common with stable coins.

Learn more here: https://dev.to/gldnwzrd/stellar-quests-level-1-manage-offers-3l93

Payment Paths

This operation allows one to send X amount of an asset (A) and have it arrive to the destination as X amount another asset (B) by hopping through 1-n offers on Stellar network's DEX (decentralized exchange). There are two operations under this belt: Path Payment Strict Send, and Path Payment Strict Receive. Strict Send will guarantee that the sender doesn't send any less or more of a chosen amount of asset A; the receiver may suffer some losses due to exchange rates. Strict Receive will guarantee that the receiver doesn't receive any less or more of a chosen amount of asset B; the sender may have to send more due to exchange rates.

Learn more here: https://dev.to/gldnwzrd/stellar-quests-level-1-path-payments-4khc

Outro

I plan on writing corresponding blog posts with relevant code examples. For now, I'm simply learning the basics of the Stellar blockchain and utilizing the Stellar Laboratory in order to interact with the test net. If you wish to learn about the Stellar blockchain, and earn while doing it, then please visit: https://quest.stellar.org/

Stellar Quests Level 1: Path Payments

Marlon — Tue, 25 Oct 2022 21:21:04 +0000

What are Path Payments?

Similar to Payments, a Path Payment is the transfer of currency from one party/person/thing to another, but the difference is that the recipient will receive their desired currency rather than what was originally sent from the source. Payments are sent directly from one account to another, while a Path Payment goes through the Stellar DEX (decentralized exchange) and/or liquidity pools before reaching the recipient.

In order for a Path Payment to work, there needs to be sufficient buy/sell offers on the DEX or a liquidity pool exchange path. There are times when a path payment will need to take several hops before reaching its destination, and although the transaction can fail when there aren't sufficient offers or liquidity pools, this operation is still "convenient".
Account A sells XLM → [buy XLM / sell ETH → buy ETH / sell BTC → buy BTC / sell USDC] → Account B receives USDC
There are two different operations for Path Payments: path payments "strict send", and path payment "strict receive". These two operations act in a different manner: the first, Strict Send, will make sure that the amount sent from the source is exact while the amount received by the destination may be less depending on conversion rates; and the second, Strict Receive, will make sure that the amount received by the destination is exact while the amount sent from the source may be less or more- also depending on conversion rates.

Both Path Payment Strict Send and Path Payment Strict Receive, on the Stellar blockchain, are operation types that must be selected when building a transaction. NOTE: Don't confuse transactions with operations- a single transaction can perform many different types of operations, and can also bundle many operations into the single transaction.

Path Payment Strict Send

Strict Send path payments are created by building a transaction of operation type "Path Payment Strict Send". This operation asks for seven inputs: destination, sending asset, send amount, intermediate path, destination asset, minimum destination amount, and source account. The Destination is the public key of the account that will receive the payment. The Sending Asset is the form of value one will send to the destination; this can be the native asset Lumen ($XLM), or a custom asset. NOTE: In order for a destination to receive a custom asset, they must've established a trustline for it. The Sending Amount is the exact total of an asset one will send to the destination. The Intermediate Path specifies the assets one wants the payment to path through; this input is optional because it gives greater control to organizations if needed. The Destination Asset is the form of value received by the destination. The Minimum Destination Amount is the min amount of an asset that must be received by the destination; which can cause a transaction to fail is there aren't sufficient buy/sell offers or liquidity pools available to guarantee the minimum. The Source Account is the public key of the account that'll be making the path payment; this input is optional because if the value won't be sent by the account which has built the transaction, then the public key entered here will refer to the account that will send the value. NOTE: All transactions MUST be signed off by all source accounts mentioned; in this case, the account which built the transaction and the account which is actually making the path payment.

Path Payment Strict Receive

Strict Receive path payments are created by building a transaction of operation type "Path Payment Strict Receive". This operation asks for seven inputs: destination, sending asset, maximum send amount, intermediate path, destination asset, destination amount, and source account. The Destination is the public key of the account that will receive the payment. The Sending Asset is the form of value one will send to the destination; this can be the native asset Lumen ($XLM), or a custom asset. NOTE: In order for a destination to receive a custom asset, they must've established a trustline for it. The Maximum Sending Amount is the max amount of an asset one is willing to send to the destination; which can cause a transaction to fail is there aren't sufficient buy/sell offers or liquidity pools available to guarantee the maximum. The Intermediate Path specifies the assets one wants the payment to path through; this input is optional because it gives greater control to organizations if needed. The Destination Asset is the form of value received by the destination. The Destination Amount is the exact total of an asset one will receive from the source. The Source Account is the public key of the account that'll be making the path payment; this input is optional because if the value won't be sent by the account which has built the transaction, then the public key entered here will refer to the account that will send the value. NOTE: All transactions MUST be signed off by all source accounts mentioned; in this case, the account which built the transaction and the account which is actually making the path payment.

Outro

Stellar Quests Level 1: Manage Offers

Marlon — Fri, 21 Oct 2022 22:16:34 +0000

What are Offers?

An offer, on the Stellar blockchain, is when a party/person/thing decides to buy/sell one asset for another at a specific exchange rate; ex. I want to sell 100 XLM for 1,000 SALT. This takes place on Stellar's decentralized exchanged (DEX). There are three different types of offers on Stellar: Buy Offer, Sell Offer, and Passive Sell Offer. Technically, all offers are both buy/sell offers. The difference in wording is to help others "reason" about their offers.

How promptly an offer is executed depends on whether or not there's a relevant counter offer on the decentralized exchange (DEX). If there aren't any relevant counter offers, then the offer will sit until a counterparty takes it or until it's removed.

Manage Buy Offer

Buy offers are created by building a transaction of operation type "Manage Buy Offer". This operation asks for six inputs: selling, buying, buy amount, price, offer id, and source. Selling is the asset you're giving in exchange. Buying is the asset you're getting in exchange. The Amount is the required total of the buying asset you want to receive for this offer. The Price is the "price of one unit of buying in terms of selling"; so if we're selling 100 XLM for 1000 SALT, then each unit of SALT we're buying costs .10. Offer ID tells the transaction to do one of two things: create a new offer (Ex. 0), or update an existing one (Ex. 3948329). The Source Account is the public key of the account that'll be creating the offer; this input is optional because if the offer won't be created by the account which has built the transaction, then the public key entered here will refer to the account that will create the offer. NOTE: All transactions MUST be signed off by all source accounts mentioned; in this case, the account which built the transaction and the account which is actually creating
the offer.

Manage Sell Offer

Sell offers are created by building a transaction of operation type "Manage Sell Offer". This operation asks for six inputs: selling, buying, buy amount, price, offer id, and source. Selling is the asset you're giving in exchange. Buying is the asset you're getting in exchange. The Amount is the required total of the buying asset you want to receive for this offer. The Price is the "price of one unit of selling in terms of buying"; so if we're buying 100 XLM with 1000 SALT, then each unit of XLM we're buying costs 10. Offer ID tells the transaction to do one of two things: create a new offer (Ex. 0), or update an existing one (Ex. 3948329). The Source Account is the public key of the account that'll be creating the offer; this input is optional because if the offer won't be created by the account which has built the transaction, then the public key entered here will refer to the account that will create the offer. NOTE: All transactions MUST be signed off by all source accounts mentioned; in this case, the account which built the transaction and the account which is actually creating
the offer.

Passive Sell Offer

This is a concept I'm still struggling to understand because the definition itself has a lot of contradictions- lol. Take a look...

A Passive Sell Offer creates an offer to sell one asset for another without taking a reverse offer of equal price (??? Okay). This allows you to maintain an order book that both buys and sells an asset equally without the offers actually executing (??? What).

Outro

Stellar Quests Level 1: Change Trust

Marlon — Thu, 20 Oct 2022 19:42:42 +0000

What are Trustlines?

A trustline, on the Stellar blockchain, is an one way agreement between two accounts. The source account that's making the agreement decides to trust another account. The trust is based on a custom asset (ex. "$ROCK") where Account-A decides that they would like to hold/sell/trade the custom asset issued by Account-B because they believe it to be of value. NOTE: Custom assets are never actually created- they only exist in the form of trust on other accounts; I'll cover this concept more in depth in a future blog post.

How are Trustlines created?

Trustlines are created by building a transaction of operation type "Change Trust". This operation asks for three inputs: asset, trust limit, and source account. The Asset is the custom asset one decides to trust; this field requires the asset code (ex. ROCK) and the issuer account id (public key of the account that issued the custom asset). The Trust Limit is a number that represents the max amount of units, of a custom asset, that you're willing to trust; if set to 1,000, then the account creating the trustline will only be able to hold 1,000 units of the custom asset. The Source Account is the public key of the account that'll be creating the trustline; this input is optional because if the trustline won't be created by the account which has built the transaction, then the public key entered here will refer to the account that will create the trustline. NOTE: All transactions MUST be signed off by all source accounts mentioned; in this case, the account which built the transaction and the account which is actually creating
the trustline.

I plan on writing corresponding blog posts with relevant code examples. For now, I'm simply learning the basics of the Stellar blockchain and utilizing the Stellar Laboratory in order to interact with the test net. If you wish to learn about the Stellar blockchain, and earn while doing it, then please visit: https://quest.stellar.org/

Stellar Quests Level 1: Payment

Marlon — Wed, 19 Oct 2022 20:06:00 +0000

What is a Payment?

Payments are the transfers of value from one party/person/thing to another, and they're the corner stone of all blockchains. Payments on the Stellar blockchain are theoretically no different from payments on any other blockchain.

A payment, on the Stellar blockchain, is an operation type that must be selected when building a transaction. NOTE: Don't confuse transactions with operations- a single transaction can perform many different types of operations, and can also bundle many operations into the single transaction.

How are Payments created?

Payments are created by building a transaction of operation type "Payment". This operation asks for four inputs: destination, asset, amount, and source account. The Destination is the public key of the account that will receive the payment. The Asset is the form of value one will send to the destination; this can be the native asset Lumen ($XLM), or a custom asset. NOTE: In order for a destination to receive a custom asset, they must've established a trustline for it. The Amount is the total of an asset one will send to the destination; the ratio is 1:1. The Source Account is the public key of the account that'll be making the payment; this input is optional because if the amount won't be sent by the account which has built the transaction, then the public key entered here will refer to the account that will send the amount. NOTE: All transactions MUST be signed off by all source accounts mentioned; in this case, the account which built the transaction and the account which is actually making the payment.

I plan on writing corresponding blog posts with relevant code examples. For now, I'm simply learning the basics of the Stellar blockchain and utilizing the Stellar Laboratory in order to interact with the test net. If you wish to learn about the Stellar blockchain, and earn while doing it, then please visit: https://quest.stellar.org/

Stellar Quests Level 1: Create Account

Marlon — Tue, 18 Oct 2022 16:04:34 +0000

What are Stellar accounts?

Accounts on the Stellar blockchain are the "central data structure which hold balances, sign transactions, and issue assets". Each account needs a keypair and the required minimum balance of Lumens ($XLM) in order to exist.

How are Accounts created?

Before an account can be created, a keypair needs to be generated. A keypair itself does NOT instantiate an account. The Stellar blockchain implements this rule so that there isn't an abundance of unused accounts. In order for an account to be instantiated, one must first send at least 1 Lumen ($XLM) to the public key address.

This gets done by building a transaction of operation type "Create Account". This operation asks for three inputs: destination, starting balance, and source account. The Destination would be the public key from the keypair that was generated. The Starting Balance is the amount one wishes to fund the new account with; which must be greater than 1 Lumen ($XLM). The Source Account is the public key of the account that will be sending the funds; plus, this input is optional because if the funds will not be sent by the account which has built the transaction, then the public key entered here will refer to the account that is. NOTE: All transactions MUST be signed off by all source accounts mentioned; in this case, the account which built the transaction and the account which is funding the new account.

Accounts and their balances

Accounts may hold different balances of different types of assets. There are two types of assets. There's the native asset "Lumen ($XLM)", and then there are "custom assets". In future blog posts, I'll be covering custom assets and how they're established.

I plan on writing corresponding blog posts with relevant code examples. For now, I am simply learning the basics of the Stellar blockchain and utilizing the Stellar Laboratory in order to interact with the test net. If you wish to learn about the Stellar blockchain, and earn while doing it, then please visit: https://quest.stellar.org/

Lifecycle Of A Blockchain Transaction

Marlon — Wed, 27 Apr 2022 02:28:07 +0000

First, I want to thank Patrick McCorry for making all of this knowledge available to myself and others.

Second, I'd like to assert that I'm writing from a Bitcoin and Ethereum paradigm, but these principles apply to most blockchains.

Overview

We'll be looking at the lifecycle of a transaction that can be broken down into three simple steps: (1) a user sends a transaction to the peer-to-peer network, (2) pending transactions eventually reach block producers, and (3) the fee market entices block producers (miners) to pick transactions for the next block. In order to expand on each of these points, we'll cover what peers (nodes) and block producers (miners) are in detail. In a following blog, we'll go over exactly what users are, and how they interact with the blockchain network.

Peers Of A Peer-To-Peer Network

The peers of a peer-to-peer (P2P) network are essentially us, the people, represented as nodes (computers). Being a peer on the P2P network boils down to stabilizing a network where financial incentives lie, or altruistically.

As a peer (node) on the network, you offer connection slots, propagate messages, and serve history. Connection slots are connections to a small group of peers (nodes) to help form a mesh network where nodes connect directly, dynamically, and non-hierarchically to as many other nodes as possible to cooperate with one another. The propagation of messages acts as a filter where nodes check the validity of transactions and blocks before passing them onto their peers. Serving history helps new peers catch up on the network by providing historical blocks.

Peers are able to connect with other peers through two approaches: (1) trusted DNS seeds (hard-coded) and (2) advertisements on the network. DNS seeds are servers which return trusted IP addresses (peers) that when connected to can be sent requests for a list of active peers (IP addresses; up to 1,000) on the network that are ranked by the DNS seed's reputation algorithm. Advertising on the network is done by sharing your nodes connection details to its closest peers (or initial connections) who will then advertise the details to their closest peers.

There are two types of connections peers are able to have: incoming and outgoing. Incoming connections happens when a peer wants to connect their node with your node. An outgoing connection happens when you want to connect your node with a peer's node. It's important to have both incoming and outgoing connections because this increases the availability of connection slots, and prevents one from a solar eclipse attack- where a peer's point-of-view is controlled by malicious agents who choose to feed the peer incorrect information. Connecting to at least one honest peer guarantees that you'll always be able to discern the truth and follow the correct (longest/heaviest) blockchain.

In order for a transaction to be propagated throughout the entire network, a user must advertise a transaction to a single peer on the network. The peer in turn makes an announcement to all of its connected peers sending a hash of the transaction (fixed byte value rather than the full transaction payload), and the connected peers receiving the announcement will determine whether or not they have the transaction payload already by querying their local replicated database with the transaction hash. If the connected peer doesn't already have the transaction payload, then they'll request it from the initial peer that made the announcement to begin with- then, the connected peer makes an announcement just like the initial peer until finally every peer on the network has the transaction payload (data) in their local replicated database.

The reason peers propagate a transaction hash first rather than the transaction payload is to save on bandwidth consumption used by the network. If a connected peer already has the transaction payload, then there's no reason to send it over.

Each peer (node) has a memory pool- which is a pending list of transactions that have been propagated, but not confirmed within a newly produced block. Memory pools are a local policy implemented by nodes and have nothing to do with consensus (agreement of the network), and they help mitigate flood protection on the network by relatively synchronizing transaction lists across all peers. Flood attacks are costly to perform as every transaction included in the blockchain will be charged a fee. In Bitcoin, duplicate transactions pay the minimum transaction fee- but in Ethereum, they pay a 10% fee bump.

There are different types of nodes that support the network: full, archival, pruned, and light-client. Every node validates blocks and transactions in real-time, except light-clients. Full nodes keep a copy of all historical blocks, and makes a copy of the database publicly available. Archival nodes (a.k.a. indexed nodes) keep a snapshot of the state of the database for every block produced. Light-client nodes keep a collection of it's own data (user activity), and a very shallow copy of the blockchain (block headers).

The ultimate goal of a peer-to-peer network is data availability and message propagation; which guarantees that new blocks are publicly available, and that anyone (without bounds) can send a message to all peers on the network.

Block Producers Of A Blockchain

The block producers (miners) of a blockchain are essentially entities with financial incentive to produce the next block. They provide a simple service, and don't run the network. They're incentivized to be honest, but should not be trusted. Block producers are able to produce a block that doesn't follow protocol, but the P2P network will reject it and it'll cost the block producer money. Their activity can be broken down to this: order transactions within a block, and extend the longest chain with the block.

In order for a block producer to be chosen to produce the next block for the blockchain, he/she/it must win the leader election. There is a tricky question which comes into play here: how do we create a list candidates when there's no strong notion of identity? There's isn't a trusted identity to create such a list either. The answer to this question is Proof Of X (work/stake); where one proves ownership over a scarce resource that should be limited and expensive to acquire. In the Nakamoto Consensus algorithm, there are two ways to win the leader election: self-selection, and proportional-selection. Self-selection is where participants (block producers) purchase resources and register. Proportional-selection is where participants are elected to become the leader proportional to their ownership of resources.

The leader election is not a free game to play, and only works if the miner (block producer) can cover costs of producing a new block and return a profit still. There are two types of cost associated with being a block producer: upfront costs to purchase hardware or tokens, and on-going costs to participate which includes electricity and computation bandwidth. There are two revenue streams that come from being a block producer: network fees, and the issuance of new coins (tokens). Network fees are collected from user transactions (included the block produced), and issuance fees are a protocol reward which subsidizes the block producer with newly minted coins. The long term plan for Bitcoin is to rely solely on network fees to reward the miners because eventually all 21 million Bitcoins will have been minted and issued.

Producing blocks of transactions is a knapsack problem- the space of a block is limited, and the block producer (miner) wants to fill the bag with transactions that'll return the most profit. Every user transaction carries with it a weight (byte size/ gas limit) and value (fee paid to the miner), so the block producer can determine which transactions they'd like to include in a newly produced block. This is why transactions are confirmed eventually, and why some transactions take a lot longer to confirm than others.

The Cryptography In Cryptocurrency

Marlon — Mon, 18 Apr 2022 00:12:45 +0000

First, I want to thank Patrick McCorry for making all of this knowledge available to myself and others.

Second, I'd like to assert that I'm writing from a Bitcoin and Ethereum paradigm, but these principles apply to most blockchains.

Overview

We'll be looking at cryptography's role in cryptocurrency. Cryptography is not always used for data privacy. In cryptocurrency, it's used for protecting integrity, verifying transactions, and authenticating users- simply put, traceability. We won't be going over user authentication in this blog- but stay tuned!

The Hash Function

Q: What is a cryptographic hash function?
A: A function that can be used to map data (preimages) of arbitrary size to fixed-size values (hashes). The values returned by a hash function are called hash values, hash codes, digests, or simply hashes. Any change made to the preimage will result in a totally unique hash.

Three Properties The Hash Function

Preimage Resistance
- Given a hash (h), it should be difficult to find any preimage (p) such that h=hash(p). This property guarantees that the hash will give no clue as to what the preimage actually is.
Second Preimage Resistance
- Given a preimage (p1), it should be difficult to find a different preimage (p2) such that hash(p1)=hash(p2). This property guarantees you can't change your mind after making a public commitment.
Collision Resistance
- It should be difficult to find two different preimages (p1) (p2) such that hash(p1)==hash(p2). This is very similar to second preimage resistance except that collision resistance pertains to hash tables (maps), and second preimage resistance pertains to public commitments.

The Chain In Blockchain

In Bitcoin and Ethereum, each block appended at the end of the blockchain has a block header that contains a hash of the previous block's header as a way of pointing to the block that came before it. This creates a weighted blockchain where the heaviest (longest) chain is considered to be the "real" blockchain.

Verifying Transactions In The Blockchain

Each block header comes with a hash tree root that is a commitment to all transactions in the block (a hash of hashes of transactions).

Verifying that a transaction was confirmed in the blockchain is simply a matter of requesting information from a SPV (Simplified Payment Verification) client. The request to a SPV client carries with it the transaction we want to verify, the block id where the transaction is located, and a couple hashed transactions from the same block that will enable us to re-compute the hash tree root. If the re-computed hash tree root is equal to the original, then it's safe to say that this transaction was indeed verified and confirmed.

High Level Understanding Of Smart Contracts In Ethereum

Marlon — Fri, 15 Apr 2022 03:36:56 +0000

First, I want to thank Patrick McCorry for making all of this knowledge available to myself and others.

Second, I'd like to assert that I'm writing from an Ethereum paradigm.

Overview

We'll be looking at smart contracts to cover what they are and how they're used in relation to Ethereum.

What Is A Smart Contract?

"A smart contract is a computerized transaction protocol that executes the terms of a contract. The general objectives are to satisfy common contractual conditions (such as payment terms, liens, confidentiality, and even enforcement), minimize exceptions both malicious and accidental, and minimize the need for trusted intermediaries." -Nick Szabo (1994)

Simply put, a smart contract will guarantee immutability of code (never modified), atomic operations of code (all or nothing), and public accessibility of code (no secrets).

Smart Contracts In Ethereum

There are two types of accounts in Ethereum's database: externally owned accounts and contract accounts. Externally owned accounts are controlled by individuals (keys), and contract accounts are controlled by code (smart contracts) and storage.

Contract accounts are the reason for two of the three types of transactions on Ethereum: creation transactions, and invocation transactions. Creation transactions carry smart contract code in their payload that get instantiated as an account in the Ethereum database. After a smart contract has been created by a creation transaction, invocation transactions become possible. Invocation transactions carry commands in their payload to invoke code in the target contract- that's stored in the database- that updates the state of the database.

How Are Smart Contracts Built

Solidity: Type language; object oriented.
Ethereum Virtual Machine: Every peer on the network has an instance of the EVM their local machine; each peer deterministically executes code (transactions).
Event Driven Programs: Smart contracts don't run themselves. Every transaction made to the blockchain (Ethereum database) costs "gas" (a unit of measurement for computation).