Merge pull request #840 from onflow/nialexsan/693-move-transactions

move transactions

docs/build/basics/transactions.md

@@ -1,5 +1,6 @@
 ---
 sidebar_position: 3
+keywords: [Flow Transaction Speed, Flow Transaction Time, Transactions on Flow]
 ---
 
 # Transactions
@@ -8,10 +9,11 @@ Transactions are cryptographically signed data messages that contain a set of in
 
 ![Screenshot 2023-08-17 at 13.57.36.png](_transactions_images/Screenshot_2023-08-17_at_13.57.36.png)
 
-<Callout type="tip">
+:::tip
+
 Transactions on Flow are fundamentally different from those on Ethereum. The main purpose of a transaction is not to send funds but to contain code that gets executed. This makes transactions very flexible and powerful. In addition to being able to access the authorizing accounts private assets, transactions can also read and call functions in public contracts, and access public domains in other users' accounts Transactions on Flow also feature different roles, such as defining third-party payer accounts, proposer accounts, and authorizers, which we will talk about in detail soon.
 
-</Callout>
+:::
 
 In order for a transaction to be valid and executed it must contain signatures from accounts involved as well as some other information, let’s take a look at all the required fields.
 
@@ -115,23 +117,66 @@ The transaction status represents the state of a transaction on the Flow blockch
 - Sealed - The verification nodes have verified and agreed on the result of the transaction and the consensus node has included the seal in the latest block.
 - Expired - The transaction was submitted past its expiration block height.
 
-<Callout type="danger">
+:::danger
+
 It is **important to differentiate the transaction status and transaction result**. Transaction status will only provide you with information about the inclusion of the transaction in the blockchain, not whether the transaction was executed the way you intended. **A transaction can still fail to execute the way you intended and be sealed.**
 
-</Callout>
+:::
 
 ### Transaction Result
 
 Once a transaction is executed, its result will be available, providing details on its success or any errors encountered during execution. It also includes events the transaction may have emitted. 
 
 ![Screenshot 2023-08-17 at 16.29.30.png](_transactions_images/Screenshot_2023-08-17_at_16.29.30.png)
 
-<Callout type="danger">
+:::danger
+
 From a developer perspective, a transaction is only successful if:
 
 - It is sealed
 - It didn’t encounter errors
-</Callout>
+
+:::
+
+## Transaction Time
+
+Understanding how transaction times work across different blockchains is crucial for developers and users to optimize their operations and expectations. Flow’s multi-node architecture allows for some of the fastest transaction times and finality times across chains. Read on for more detail on how it works and what it means for developers and users.
+
+### Two Key Transaction Questions
+
+Whenever a transaction is processed, two primary questions come to mind:
+
+1. **Inclusion**: Will this transaction be included in the final chain?
+2. **Result**: What is the outcome of the transaction?
+
+Different blockchains tackle these questions in varied sequences. For instance, Bitcoin and Ethereum provide answers simultaneously. Layer 2 solutions (L2s) can sometimes address the outcome before confirming inclusion. But there's a catch: you can have an answer to those questions that might be wrong. Flow, on the other hand, prioritizes the inclusion question.
+
+### Transaction Finality
+
+Drawing a parallel to traditional finance, a vendor might instantly know if Visa approves a transaction, but the possibility of chargebacks lingers for weeks. This uncertainty introduces the concept of "finality" in blockchain transactions.
+
+In the dominant Proof-of-Stake (PoS) environment, which includes most chains except for Bitcoin, there are three key finality stages:
+
+- **Preliminary result**: It's an initial answer to the aforementioned questions. The preliminary result doesn’t ensure correctness, and there are no economic penalties (like "slashing") if the informant provides false information.
+- **Soft economic finality**: This stage provides an answer backed by cryptographic proof. If the informant is deceptive, they face economic repercussions or "slashing."
+- **Hard economic finality**: The provided answer either holds true, or the entire blockchain requires a restart. The latter case sees at least one-third of the nodes facing economic penalties.
+
+![finality.png](./_transactions_images/finality.png)
+
+### Chain Comparisons
+
+Chain    | Preliminary |  Soft finality | Hard finality 
+---------|-------------|----------------|---------------
+Solana   | 100ms       | n/a            | ~30s
+Ethereum | 15s         | n/a            | ~15m
+Flow     | bypass      | 6s             | ~20s 
+
+#### Flow
+
+Flow bypasses preliminary results entirely. It reaches soft finality ("Executed") in about 6 seconds and hard finality ("Sealed") in around 20 seconds. If an Access Node on Flow states a transaction has occurred, it's either correct or cryptographic proof exists that can lead to the node's slashing.
+
+![transaction-time.png](_transactions_images/chain-comparison.png)
+
 
 ## Signing a Transaction
 
@@ -150,39 +195,43 @@ A transaction can contain two types of signatures: **payload signatures** and **
 
 The transaction payload is the innermost portion of a transaction and contains the data that uniquely identifies the operations applied by the transaction as we have defined them above. In Flow, two transactions with the same payload will never be executed more than once.
 
-<Callout type="warning">
+:::warning
+
 ⚠️ The transaction proposer and authorizer are only required to sign the transaction payload. These signatures are the payload signatures.
 
-</Callout>
+:::
 
 ### Authorization Envelope
 
 The transaction authorization envelope contains both the transaction payload and the payload signatures.
 
 The transaction payer is required to sign the authorization envelope. These signatures are **envelope signatures**.
 
-<Callout type="danger">
+:::danger
+
 Special case: if an account is both the payer and either a proposer or authorizer, it is required only to sign the envelope.
 
-</Callout>
+:::
 
 ### Payment Envelope
 
 The outermost portion of the transaction, which contains the payload and envelope signatures, is referred to as the payment envelope.
 
-<Callout type="danger">
+:::danger
+
 Special case: if an account is both the payer and either a proposer or authorizer, it is required only to sign the envelope.
 
-</Callout>
+:::
 
 ### Payer Signs Last
 
 The payer must sign the portion of the transaction that contains the payload signatures, which means that the payer must always sign last. This ensures the payer that they are signing a valid transaction with all of the required payload signatures.
 
-<Callout type="danger">
+:::danger
+
 Special case: if an account is both the payer and either a proposer or authorizer, it is required only to sign the envelope.
 
-</Callout>
+:::
 
 ### Signature Structure
 
@@ -203,10 +252,11 @@ Sequence numbers work similarly to transaction nonces in Ethereum, but with seve
 - **Each key in an account has a dedicated sequence number** associated with it. Unlike Ethereum, there is no sequence number for the entire account.
 - When creating a transaction, only the **proposer must specify a sequence number**. Payers and authorizers are not required to.
 
-<Callout type="tip">
+:::tip
+
 The transaction proposer is only required to specify a sequence number for a single account key, even if it signs with multiple keys. This key is referred to as the proposal key.
 
-</Callout>
+:::
 
 Each time an account key is used as a proposal key, its sequence number is incremented by 1. The sequence number is updated after execution, even if the transaction fails (reverts) during execution.
 

docs/evm/accounts.md

@@ -36,7 +36,7 @@ COAs create powerful new opportunities to improve the UX, functionality and util
 
 - **Atomic Interactions**: Developers are able to execute multiple EVM transactions atomically from a COA, which is not possible using traditional EVM accounts. This is particularly useful for applications that require multiple transactions to be executed within a single block, or require that prior transactions' state changes revert if a subsequent transaction fails.
 
-- **Native Account Abstraction**: COAs are controlled by Cadence resources, which are in turn owned by Flow accounts. [Flow accounts](./accounts.md) have built-in support for multi-signature authentication, key rotation, and account recovery. As a Cadence resource, COAs naturally inherit [these features](https://developers.flow.com/build/differences-vs-evm/account-abstraction).
+- **Native Account Abstraction**: COAs are controlled by Cadence resources, which are in turn owned by Flow accounts. [Flow accounts](./accounts.md) have built-in support for multi-signature authentication, key rotation, and account recovery. As a Cadence resource, COAs naturally inherit [these features](../build/advanced-concepts/account-abstraction.md).
 
 - **Fine-Grained Access Control**: As Cadence resources, access to a COA can be governed by more sophisticated policies than those available with basic EVM accounts. By utilizing powerful Cadence access control primitives such as [capabilities and entitlements](https://cadence-lang.org/docs/1.0/language/access-control), developers can restrict who is able to interact with a COA and what actions they are permitted to perform.
 

docs/evm/fees.md

@@ -82,7 +82,7 @@ Transaction fee = [1E-6 FLOW + (110.97 * 2.49E-07 FLOW)] x 1 = 6.55E-06 FLOW
 **Note**: Please be aware that this example serves solely for illustrative purposes to elucidate the calculations. Actual transaction fees may differ due to various factors, including the byte size of the transaction.
 </details>
 
-<h2>Gasless Transactions</h2>
-<p>Fees needed to execute transactions on a Web3 app are often a major challenge for new users and can be a barrier to adoption. Builders can easily extend their apps with Cadence to create ‘gasless’ experiences by specifying their app as the <a href="https://developers.flow.com/build/differences-vs-evm/account-abstraction#sponsored-transactions">sponsor</a> instead of the user.</p>
+## Gasless Transactions
+Fees needed to execute transactions on a Web3 app are often a major challenge for new users and can be a barrier to adoption. Builders can easily extend their apps with Cadence to create ‘gasless’ experiences by specifying their app as the [sponsor](../build/advanced-concepts/account-abstraction.md#sponsored-transactions) instead of the user.
 
 To learn more about storage fee and transaction fee, visit [Flow Tokenomics page](https://flow.com/flow-tokenomics/technical-overview).

src/data/pages/home.tsx

@@ -12,7 +12,7 @@ const contentNavigationListItems: ContentNavigationListProps = {
     {
       title: 'Account Abstraction',
       text: 'Enhance UX with a flexible Account structure and key management',
-      link: '/build/differences-vs-evm/account-abstraction',
+      link: '/build/advanced-concepts/account-abstraction',
       icon: 'learn',
     },
     {

src/ui/design-system/src/lib/Components/LinkGrid/index.tsx

@@ -106,11 +106,11 @@ const sections: LinkGridSection[] = [
     links: [
       {
         title: 'Account Abstraction',
-        href: '/build/differences-vs-evm/account-abstraction',
+        href: '/build/advanced-concepts/account-abstraction',
       },
       {
         title: 'Understanding Transaction Time',
-        href: '/build/differences-vs-evm/transaction-time',
+        href: '/build/basics/transactions#transaction-time',
       },
       {
         title: 'FLIX',
@@ -126,11 +126,11 @@ const sections: LinkGridSection[] = [
       },
       {
         title: 'Sponsored Transactions',
-        href: '/build/differences-vs-evm/account-abstraction#sponsored-transactions',
+        href: '/build/advanced-concepts/account-abstraction#sponsored-transactions',
       },
       {
         title: 'Multi-auth Transactions',
-        href: '/build/differences-vs-evm/account-abstraction#multi-sig-transactions',
+        href: '/build/advanced-concepts/account-abstraction#multi-sig-transactions',
       },
     ],
     imageName: 'docs-advanced',

vercel.json

@@ -1043,8 +1043,8 @@
       "permanent": true
     },
     {
-      "source": "/build/advanced-concepts/account-abstraction",
-      "destination": "/build/differences-vs-evm/account-abstraction",
+      "source": "/build/differences-vs-evm/account-abstraction",
+      "destination": "/build/advanced-concepts/account-abstraction",
       "permanent": true
     },
     {
@@ -1225,6 +1225,10 @@
       "source": "/build/smart-contracts/best-practices/design-patterns",
       "destination": "https://cadence-lang.org/docs/1.0/design-patterns",
       "permanent": true
+    },
+    {
+      "source": "/build/differences-vs-evm/transaction-time",
+      "destination": "/build/basics/transactions#transaction-time"
     }
   ]
 }