GitBook: [XDC-Community#20] No subject

SUMMARY.md

@@ -7,11 +7,8 @@
     * [Why XDC Network](get-started/blockchain-basics/why-xdc-network.md)
   * [XDC Design](get-started/xdc-design/README.md)
     * [Consensus Mechanism](get-started/xdc-design/consensus-mechanism.md)
-    * [Accounts](get-started/xdc-design/accounts.md)
-    * [Transactions](get-started/xdc-design/transactions.md)
     * [Computation](get-started/xdc-design/computation.md)
     * [Storage](get-started/xdc-design/storage.md)
-    * [Transaction Fees](get-started/xdc-design/transaction-fees.md)
     * [XDC](get-started/xdc-design/xdc.md)
     * [Tokenomics](get-started/xdc-design/tokenomics.md)
     * [Governance](get-started/xdc-design/governance.md)

get-details/account-details.md

@@ -1,2 +1,64 @@
 # Account Details
 
+An XDC account is an entity with an XDC balance able to send transactions on the XDC network. Accounts can either be deployed as smart contracts or controlled by users.
+
+### Account Types
+
+XDC has two account types:
+
+* Externally owned: Anyone with private keys can control these accounts.
+* Contract: A smart contract controlled by code and deployed on the network.
+
+Both account types can receive, hold, and send XDC tokens, on the one hand, and interact with deployed smart contracts, on the other.
+
+### Key Differences
+
+**Externally owned accounts:**
+
+* Transactions can be sent directly from the account.
+* Transactions consist solely of XDC transfers.
+* Creating an account costs nothing.
+
+**Contracts:**
+
+* Creating a contract incurs costs since network storage is used in the process.
+* Transactions can only be sent in response to received transactions.
+* Transactions received by a contract account from an external account trigger a code to run different actions, such as creating a new contract or transferring tokens.
+
+## An Account Examined
+
+XDC accounts have four fields:
+
+* `balance`: The number of tokens owned by the address.
+* `nonce`: It shows the number of transactions created and sent from the account and ensures that transactions are processed only once.
+* `codeHash`: The code for an account. Contract accounts have programmed code fragments that can perform different operations. Unlike the other account fields, this code, which can never be modified, gets executed if the account receives a message call. All the code fragments are stored under their corresponding hashes in the state database for later retrieval. The hash value is named as a `codeHash`. The codeHash field is the hash of an empty string for externally owned accounts.
+* `storageRoot`: Also named as a storage hash. It is a 256-bit hash of the root node that points to the root node in account storage trie.
+
+## Externally Owned Accounts and Key Pairs
+
+An account includes a cryptographic pair of keys: public and private. These keys prevent fraud by ensuring that the authorized sender, and the authorized sender alone, signed a transaction. Since the private key signs transactions, it grants custody over the funds in the associated account. Ownership of cryptocurrency is, at the bottom, just ownership of an account's private key—the funds themselves reside on the ledger.
+
+If, for example, Ana wants to send XDC from her account to Ben’s account, Ana must first create a transaction request and send it to the network for verification. XDC’s reliance on public-key cryptography enables Ana to prove that she originally created the transaction request. In the absence of any cryptographic mechanisms, a bad actor, say, Ernest, can publicly broadcast a request like “transfer10 XDC from Ana’s account to Ernest’s,” and there would be no way to verify the source of the request.
+
+## Creating an XDC Account 
+
+```
+let keyStorage = XDCKeyLocalStorage()
+let account = try? XDCAccount.create(keyStorage: keyStorage, keystorePassword: "MY_PASSWORD")
+```
+
+Create an instance of XDCClient, which will provide access to a set of functions interacting with the blockchain.
+
+```
+guard let clientUrl = URL(string: "https://apothem-or-mainnet-url") else { return }
+let client = XDCClient(url: clientUrl)
+```
+
+Now, you can interact with the client methods. For example, to get the current gas price, run the following code:
+
+```
+client.xdc_gasPrice { (error, currentPrice) in
+    print("The current gas price is \(currentPrice)")
+}
+```
+

get-details/smart-contract-details/xip-proposals.md

@@ -1,2 +1,52 @@
 # XIP Proposals
 
+## XIPs
+
+XDC Network Improvement Proposals (XIPs) describe standards for the XDC platform, including core protocol specifications, client APIs, and contract standards. Network upgrades are discussed separately.
+
+### Contributing
+
+First review XIP-1. Then clone the repository and add your XIP to it. There is a [template XIP here](https://github.com/XDC-Community/XIPs.github.io/blob/main/XIPS/xip-template.md). Then submit a Pull Request to XDC Community's [XIPs repository](https://github.com/XDC-Community/XIPs.github.io/pulls).
+
+### XIP status terms
+
+* **Idea** - An idea that is pre-draft. This is not tracked within the XIP Repository.
+* **Draft** - The first formally tracked stage of an XIP in development. An XIP is merged by an XIP Editor into the XIP repository when properly formatted.
+* **Review** - An XIP Author marks an XIP as ready for and requesting Peer Review.
+* **Last Call** - This is the final review window for an XIP before moving to FINAL. An XIP editor will assign Last Call status and set a review end date (\`last-call-deadline\`), typically 14 days later. If this period results in necessary normative changes it will revert the XIP to Review.
+* **Final** - This XIP represents the final standard. A Final XIP exists in a state of finality and should only be updated to correct errata and add non-normative clarifications.
+* **Stagnant** - Any XIP in Draft or Review if inactive for a period of 6 months or greater is moved to Stagnant. An XIP may be resurrected from this state by Authors or XIP Editors through moving it back to Draft.
+* **Withdrawn** - The XIP Author(s) have withdrawn the proposed XIP. This state has finality and can no longer be resurrected using this XIP number. If the idea is pursued at later date it is considered a new proposal.
+* **Living** - A special status for XIPs that are designed to be continually updated and not reach a state of finality. This includes most notably XIP-1.
+
+### XIP Types
+
+XIPs are separated into a number of types, and each has its own list of XIPs.
+
+#### Standard Track
+
+Describes any change that affects most or all Ethereum implementations, such as a change to the network protocol, a change in block or transaction validity rules, proposed application standards/conventions, or any change or addition that affects the interoperability of applications using Ethereum. Furthermore Standard XIPs can be broken down into the following categories.
+
+**Core**
+
+Improvements requiring a consensus fork, as well as changes that are not necessarily consensus critical but may be relevant to “core dev” discussions.
+
+**Networking**
+
+Includes improvements around devp2p, as well as proposed improvements to network protocol specifications.
+
+**Interface**
+
+Includes improvements around client API/RPC specifications and standards, and also certain language-level standards like method names and contract ABIs. The label “interface” aligns with the interfaces repo and discussion should primarily occur in that repository before an XIP is submitted to the XIPs repository.
+
+**XRC**
+
+Application-level standards and conventions, including contract standards such as token standards, name registries, URI schemes, library/package formats, and wallet formats.
+
+#### Meta
+
+Describes a process surrounding XDC Network or proposes a change to (or an event in) a process. Process XIPs are like Standards Track XIPs but apply to areas other than the XDPoS protocol itself. They may propose an implementation, but not to XDPoS's codebase; they often require community consensus; unlike Informational XIPs, they are more than recommendations, and users are typically not free to ignore them. Examples include procedures, guidelines, changes to the decision-making process, and changes to the tools or environment used in XDC Network development. Any meta-XIP is also considered a Process XIP.
+
+#### Informational
+
+Describes a XDC Network design issue, or provides general guidelines or information to the XDC community, but does not propose a new feature. Informational XIPs do not necessarily represent XDC community consensus or a recommendation, so users and implementers are free to ignore Informational XIPs or follow their advice.

get-details/smart-contract-details/xrc-standards.md

@@ -1,2 +1,13 @@
 # XRC Standards
 
+
+
+## Standards Overview
+
+The XDC community has adopted numerous standards to ensure the interoperability of projects and the composability of smart contracts and dApps.
+
+### Token Standards
+
+* XRC20: A standard interface for fungible (interchangeable) tokens such as virtual currencies.  XRC20 is a fork of ERC20, whose details can be found at [https://eips.ethereum.org/EIPS/eip-20](https://eips.ethereum.org/EIPS/eip-20)
+* XRC721: A standard interface for non-fungible (unique) tokens corresponding to real-world products such as artwork or songs.  XRC721 is a fork of ERC721, whose details can be found at [https://eips.ethereum.org/EIPS/eip-721](https://eips.ethereum.org/EIPS/eip-721)
+* XRC1155: A standard interface that enables you to create every type of asset. It allows a single contract to define and configure multiple fungible and non-fungible tokens with increased gas efficiency.  XRC1155 is a fork of ERC1155, whose details can be found at [https://eips.ethereum.org/EIPS/eip-1155](https://eips.ethereum.org/EIPS/eip-1155)

get-details/transaction-details.md

@@ -1,2 +1,116 @@
 # Transaction Details
 
+## What is a Transaction
+
+A transaction is a cryptographically signed instruction initiated by an externally owned account. Once executed, the state of the XDC network is updated. The simplest transaction involves transferring XDC from one account to another. For example, if Ben sends Ana 1 XDC, his account will be debited, and Ana's will be credited 1 XDC. Both of these state-changing actions occur in the space of a single transaction.
+
+Transactions are broadcast by nodes to the entire network to be executed on the virtual machine. A validator will execute the transaction and circulate the resulting state change to the entire network.
+
+A submitted transaction consists of the following details:
+
+* `signature`: The sender's identifier, generated by signing the transaction with the sender's private key that confirms its authorization.
+* `recipient`: The receiving address. The transaction will transfer value for an externally owned account. However, for a contract account, it will execute the contract code.
+* `value`: The amount of XDC to transfer from sender to recipient.
+* `data`: An optional field that allows the inclusion of arbitrary data.
+* `gasPrice`: The fee charged per unit of gas.
+* `gasLimit`: The maximum amount of gas units that the transaction can consume. Units of gas represent computational steps.
+
+Gas is the reference to the computational power required for a validator to execute the transaction. Users will have to pay a fee for this computation. The `gasPrice` and `gasLimit` determine the maximum transaction fee paid to the validator.
+
+The transaction object looks like this:
+
+```
+{
+  from: "0xEA674fdDe714fd879de3EdF0F56AA9516B898ec8",
+  to: "0xac03bb73b6a9e108530aff4ef5077c2b3d481e5a",
+  gasLimit: "35000",
+  gasPrice: "200",
+  nonce: "0",
+  value: "10000000000",
+  }
+  
+```
+
+A transaction object is signed using the sender’s private key, ensuring that the transaction arrived from the authorized sender and was not sent fraudulently.
+
+### **Example of a Transaction**
+
+It is necessary to have the private key associated with the sender’s address to transfer XDC from one account to another:
+
+```
+let account = try! XDCAccount.init(keyStorage: XDCPrivateKeyStore(privateKey: "0x2b6dbb667da5962bb96fe9ae87c53a5308afeabb6f6be0be2d5f27be2efcf4d"))
+```
+
+We need to create an instance of XDCTransaction with values we want to send to the account.
+
+```
+let tx = XDCTransaction(from: nil, to: XDCAddress(xdcAddress), value: BigUInt(d3), data: nil, nonce: 3, gasPrice: BigUInt(4000004), gasLimit: BigUInt(50005), chainId: 51)
+```
+
+Now, we need to call the eth\_sendRawTransaction method.
+
+```
+client.eth_sendRawTransaction(tx, withAccount: self.account!) { (err, tx) in
+     print(tx ?? "no tx")     
+
+```
+
+We will receive one txHash, which will include all data of the transaction.
+
+#### Response:
+
+```
+     {
+  "jsonrpc": "2.0",
+  "id": 1,
+  "result": {
+    "blockHash": "0x4c5464098a8cc253157f3bba0e8f2d626691b1eb22e4465de8b8644b23b8ad76",
+    "blockNumber": "0x1496de7",
+    "from": "xdc6ffe09f9302a857fcb122296e3ab3bb80c45cbcd",
+    "gas": "0xc355",
+    "gasPrice": "0x3d0904",
+    "hash": "0x903d735683c2959b86aea197a06583a30837b4a505465a0da2347f61d6daa533",
+    "input": "0x",
+    "nonce": "0x150",
+    "to": "xdcd7813e7cfdf83d6fa3469d7411b52a50ed2b867f",
+    "transactionIndex": "0x0",
+    "value": "0x6124fee993bc0000",
+    "v": "0x8a",
+    "r": "0xaad835079b2b4753af3fba7f6423594154f3d05677b1db868dd4345009b80a31",
+    "s": "0x62cc01a1c4135286e28ba8fbf91b4c9e74c015d82be352310a11d1e0eb411148"
+  }
+}
+```
+
+The transaction’s signature hash is cryptographically proven, verifying that it came from the legitimate sender.
+
+### **Gas**
+
+As already mentioned, transactions cost gas to process. Simple transfer transactions may require 35000 units of gas.
+
+So, for Ben to send Ana 1 XDC at a `gasPrice` of 30 gwei, Ben will need to pay the following fee:
+
+`30 * 35000 = 1,050,000 gwei`
+
+`--or--`
+
+`0.00105 XDC`
+
+Ben's account is debited **-1.00105 XDC**
+
+Ana's account is credited **+1.0 XDC**
+
+The validator processing the transaction gets **+0.00105 XDC**
+
+Gas is also required for smart contract interactions.
+
+Gas is refunded to the user's account if it is not used in any transaction.
+
+### Transaction Life Cycle
+
+Once the transaction is submitted, the following occurs:
+
+1. After sending a transaction, cryptography generates a transaction hash, such as`0x903d735683c2959b86aea197a06583a30837b4a505465a0da2347f61d6daa533`
+2. The transaction is then streamed to the network and included in the pool of transactions.
+3. A validator must pick the transaction and include it in a block to verify it and consider it successful. If the network is busy and validators cannot keep up, there may be a delay. Since validators get the fees, they will always prioritize transactions with higher `gasPrice`.
+4. The transaction will get a block confirmation number. It is the number of blocks created since the transaction's block was first included. A higher number provides a certainty that the network has successfully executed and recognized the transaction. A higher block confirmation number thus ensures the immutability of the transaction.