Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Convert graphviz diagrams to raster images #19

Merged
merged 3 commits into from
Sep 27, 2022
Merged

Convert graphviz diagrams to raster images #19

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
b8b58ee
convert graphviz diagrams to png in transactions protocol :doc
lparisc Sep 27, 2022
9d3f8e5
convert graphviz diagrams to png in net protocol :doc
lparisc Sep 27, 2022
24f1a6c
convert graphviz diagrams to png in accounts protocol :doc
lparisc Sep 27, 2022
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
165 changes: 3 additions & 162 deletions docs/04_protocol/02_transactions_protocol.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -44,49 +44,7 @@ An Antelope smart contract is implemented as a C++ class that derives from `eosi

A transaction instance consists of a transaction header and the list of action instances and transaction extensions that make the actual transaction. The transaction header includes information necessary to assess the inclusion of the transaction in a block based on its expiration time, which is computed when the transaction is pushed for execution. Other fields include the block number that includes the transaction, a block ID prefix used to prevent "cross chain" or "cross fork" attacks, upper limits for CPU and network usage, and the number of seconds to delay the transaction, if applicable. The diagram below depicts a transaction instance.

```dot-svg

#transaction instance - xacts_instance.dot
#
#notes: * to see image copy/paste to https://dreampuf.github.io/GraphvizOnline
# * image will be rendered by gatsby-remark-graphviz plugin in eosio docs.

digraph {
newrank=true #allows ranks inside subgraphs (important!)
compound=true #allows edges connecting nodes with subgraphs
graph [rankdir=TB, nodesep=.33]
node [shape=box, style=filled, fillcolor=lightgray]
edge [arrowsize=.6]

subgraph cluster_instance {
label="Transaction Instance"
graph [style=solid]

xact_header [label="Transaction Header"]
xact_exts [label="Transaction Extensions"]

subgraph cluster_actions {
rank=same
label="action list"; labelloc="t"
graph [style=dashed]
node [shape=box, width=.3]
edge [arrowsize=.6]
b1 [label="action 1"]; b2 [label="action 2"]
bd [label="...", color=invis, style=""]; bn [label="action n"]
b1 -> b2 -> bd -> bn
} //cluster_actions

{
rank=same
xact_header -> xact_exts [color=invis]
}
xact_exts -> bn [color=invis]

} //cluster_instance

} //digraph

```
![](images/xacts_instance.png "Transaction Instance")

The action instances may consist of regular actions or context free actions. Signatures are created and validated at the transaction level. Accounts and permissions are handled on a per action basis. Each action instance contains information to validate whether it is authorized to be executed based on the permission levels of the actors specified in the action and the actual authorizations defined in the smart contract for that action (see [3.4.2. Permission Check](#342-permission-check)).

Expand Down Expand Up @@ -162,55 +120,7 @@ The transaction must be signed by a set of keys sufficient to satisfy the accumu

The transaction signing process takes three parameters: the transaction instance to sign, the set of public keys from which the associated private keys within the application wallet are retrieved, and the chain ID. The chain ID identifies the actual Antelope blockchain and consists of a hash of its genesis state, which depends on the blockchain’s initial configuration parameters. Before signing the transaction, the Antelope software first computes a digest of the transaction. The digest value is a SHA-256 hash of the chain ID, the transaction instance, and the context free data if the transaction has any context free actions. Any instance fields get serialized before computing any cryptographic hashes to avoid including reference fields (memory addresses) in the hash computation. The transaction digest computation and the signing process are depicted below.

```dot-svg

#transaction signing - xact_sign.dot
#
#notes: * to see image copy/paste to https://dreampuf.github.io/GraphvizOnline
# * image will be rendered by gatsby-remark-graphviz plugin in eosio docs.

digraph {
newrank=true #allows ranks inside subgraphs (important!)
compound=true #allows edges connecting nodes with subgraphs
graph [rankdir=LR, splines=ortho]
node [shape=box, style=filled]
edge [arrowsize=.5]

subgraph cluster_signed_xact {
graph [style=filled]
signed_xact [label="Signed\nTransaction", color=invis]
signatures [label="signature(s)"]
{ rank=same; signatures; signed_xact }
} //cluster_signed_xact

xact [label="Transaction"]
chainID [label="Chain ID"]
sha256 [label="SHA-256", style="", shape=oval]
xact_dig [label="Transaction\nDigest"]

{xact, chainID} -> sha256 -> xact_dig

pub_key [label="Signing account(s)\nPublic Key(s)"]

subgraph cluster_wallet_mgr {
graph [style=dashed, labelloc=b]
label="Wallet Manager"
pri_key [label="Signing account(s)\nPrivate Key(s)"]
wallet [label="Signing account(s)\nWallet"]
sign [label="Sign", style="", shape=oval]
} //cluster_wallet_mgr

{ rank=same; chainID; pub_key; wallet; pri_key }
{ rank=same; xact; sha256; sign }
{ rank=same; xact_dig; signed_xact }

pub_key -> wallet -> pri_key
{pri_key, xact_dig} -> sign
sign -> signatures

} //digraph

```
![](images/xact_sign.png "Transaction Signing")

After the transaction digest is computed, the digest is finally signed with the private key associated with the signing account’s public key. The public-private key pair is usually stored within the local machine that connects to the local node. The signing process is performed within the wallet manager associated with the signing account, which is typically the same user that deploys the application. The wallet manager provides a virtual secure enclave to perform the digital signing, so a message signature is generated without the private key ever leaving the wallet. After the signature is generated, it is finally added to the signed transaction instance.

Expand Down Expand Up @@ -244,76 +154,7 @@ If there is at least one actor whose set of named permissions fail to meet the m

The diagram below depicts an action instance. It consists of the receiver account, the action name, the list of actors and their permissions, and the action data containing the message to be sent, if any, to the receiver account.

```dot-svg

#action instance - xacts_act_instance.dot
#
#notes: * to see image copy/paste to https://dreampuf.github.io/GraphvizOnline
# * image will be rendered by gatsby-remark-graphviz plugin in eosio docs.

digraph {
newrank=true #allows ranks inside subgraphs (important!)
compound=true #allows edges connecting nodes with subgraphs
graph [rankdir=TB, nodesep=.2, ranksep=.1, style=solid]
node [shape=box, style=filled, fillcolor=lightgray, height=.25]
edge [arrowsize=.6, color=invis, minlen=1]

subgraph cluster_instance {
label="Action Instance"

subgraph cluster_w {
graph [style=invis]
label=""
empty_node [label="", color=invis, style="", width=1.1]
act_name [label="action name"]
acct_name [label="account name"]
} //cluster_w

subgraph cluster_perms {
label="authorization list"; labelloc=t
graph [style=dashed]
node [shape=box, width=.3]
edge [arrowsize=.6]
#
subgraph cluster_perm_n {
label="auth n"; labelloc=t
an [label="actor n"]; pn [label="permission n"]
an -> pn
}
subgraph cluster_perm_e {
label=""; labelloc=t
graph [color=invis]
node [color=invis, style=""]
ae [label="..."]
}
subgraph cluster_perm_2 {
label="auth 2"; labelloc=t
a2 [label="actor 2"]; p2 [label="permission 2"]
a2 -> p2
}
subgraph cluster_perm_1 {
label="auth 1"; labelloc=t
a1 [label="actor 1"]; p1 [label="permission 1"]
a1 -> p1
}
{ rank=same; a1; a2; ae; an }
} //cluster_perms

acct_name -> a2

subgraph cluster_data {
graph [style=invis]
label=""
act_data [label="action data", width=5.25]
} //cluster_data

p2 ->act_data
} //cluster_instance

} //digraph

```

![](images/xacts_act_instance.png "Action Instance")

### 3.4.4. Authority Check

Expand Down
Loading