in the previous chapter we got a lot of
information about transactions and the
various consensus mechanisms in
substrate
and in this chapter we will build up on
our knowledge of substrate by delving
into the concepts
of State Transitions and storage and
then learning about Concepts around
accounts addresses and keys and then
learning about all the off-chain
operations and then finishing it off
with some more information on
cross-consensus communication so let's
get started in this section we will
learn how the transaction is taking
place on substrate are stored in the
database and what types of storages are
used key value databases substrate
implements its storage database with
rocksdb a persistent key value store for
fast storage environments
it also supports an experimental parity
DB the DB is used for all the components
of substrate that require persistent
storage such as substrate clients
substrate like clients and off-chain
workers
try abstraction
one advantage of using the simple key
value storage is that you're able to
easily abstract storage structures on
top of it substrate uses a base 16
modified Merkel patriarchy to provide a
try structure whose contents can be
modified and whose root hash is
recalculated efficiently
tries allow efficient storing and
sharing of the historical block State
the try route is a representation of the
data within the try that is two tries
with different data will always have
different rules thus two blockchain
nodes can easily verify that they have
the same state by simply comparing the
try roots and this concept is known as
try abstraction querying storage it's
blockchains that are built with
substrate exposure remote procedure call
server that can be used to query runtime
storage
when you use the substrate RPC to access
a storage item you only need to provide
the key associated with that item
substrates runtime storage apis expose a
number of storage item types this makes
it extremely easy to access or query the
storage and is one of the features that
makes substrate so popular
now let's learn about accounts addresses
and keys an account represents an
identity usually of a person or an
organization that is capable of making
transactions or holding funds
although accounts are most often used to
represent a person that doesn't have to
be the case an account can be used to
perform operations on behalf of a user
or another entity or to perform
operations autonomously in addition any
single person or entity could have
multiple accounts for different purposes
and in this section we will learn a bit
more about this in general every account
has an owner who possesses a public and
private key pair the private key is a
cryptographically secure sequence of
randomly generated numbers the private
key generates a random sequence of words
called a secret seed phrase or mnemonic
the secret seat phrase is important
because it can be used to recover to an
account if the private key is lost you
may have experienced a seed phrase when
you signed up for a wallet such as
metamask an account is usually defined
as a public address with a public
private key pair but in runtime there's
a small difference and it's important
for us to know how it works to avoid
confusion in the future in a runtime
built with frame an account is defined
as a storage map with a 32 byte address
identifier and corresponding account
information
such as the number of transactions the
account has made the number of modules
that depend on the count and the count
patterns with substrate different chains
can Implement different rules for how
accounts and the keys that control them
are used and these are called as
specialized accounts in most cases
specialized accounts are implemented in
the context of a specific frame palette
either in a pre-built palette like
staking or multi-sig or in custom
pallets that you design
there are usually two types of
specialized accounts multi-signature
accounts typically an account has one
and only owner and that owner holds the
private key for signing transactions the
multi-sig pallet enables you to
configure A specialized account for
executing transactions that multiple
account holders must approve
and proxy and keyless accounts the proxy
palette provides another way you can
configure specialized accounts for a
substrate based chain using frame with
proxy accounts primary account owners
can designate one or more other accounts
on to act on behalf of themselves proxy
accounts can be used to add a layer of
security by isolating primary account
funds from accounts assigned to specific
roles that can complete tasks on behalf
of the primary account of chain
operations
there may be instances where you want to
query off-chain data and utilize it and
the conventional way of doing this is by
using oracles
but there's a limitation to the security
scalability and infrastructure
efficiency that oracles can provide
substrate provides us with a few
features to make it easy for us to
support option operations off-chain
workers enable you to move tasks that
might require more time to execute than
allowed out of the block processing
pipeline any tasks that might take
longer than the maximum block execution
time is a reasonable candidate for
off-chain processing such as website
requests and random number generation
since off-chain workers work with data
that's off-chain they need a way to
store the information and that is why we
have off-chain storage which is storage
that is local to a substrate node and
can be accessed by both off-chain
workers and on-chain logic off chain
workers have both read and write access
to off-chain storage and on chain logic
has write access through option indexing
but doesn't have read access on-chain
state is expensive because it must be
agreed upon and populated to multiple
nodes in the network therefore we have
off chain index an optional service that
allows the runtime to write directly to
the offschain storage independently from
off-chain workers the option index
provides temporary storage for on-chain
logic and complements the on-chain state
gross consensus communication relies on
a message format xcm that is designed to
provide a generalized and extensible set
of instructions for completing
transactions across boundaries created
by different consensus systems
transaction formats and transport
protocols the xcm format expresses the
contents of the message
each message consists of a set of
instructions being requested by a sender
that can be accepted or rejected by a
message recipient
in this section we will learn about four
Concepts the type of message protocols
available
the properties of the messages in the
xcm format and two things that XM
depends heavily on location and assets
so let's get started with message
protocols
ecosystem there are three main
communication channels the message
protocols used to transport messages
between chains just upward message
passing enables a parachain to pass
messages up to its relay chain and
downward message passing enables the
relay chain to pass messages down to a
pair chain
cost consensus message passing enables
para chains to exchange messages with
other para chains that are connected to
the same religion there are four
important properties of the messages
that use the xcm format messages are
asynchronous they're absolute asymmetric
and agnostic
Axiom needs a way to Express locations
in a general and unambiguous way for
example xcm must be able to identify the
location for the following types of
activities where instructions should be
executed where an asset should be
withdrawn from and where an account to
be received assets can be found
for any of these activities the location
might be in the context of a relay chain
a parachain a foreign chain an account
in a specific chain a specific smart
contract or an individual palette
most blockchains depend on some type of
digital asset to provide economic
incentives that are crucial to the
security of the network
some blockchains support a single native
asset other blockchains allow multiple
assets to be managed on chain for
example
assets defined in smart contracts or
non-native tokens
there are also blockchains that support
non-fungible digital assets for
one-of-a-kind collectibles
for xcm to support these different types
of assets it must be able to express
Assets in a general flexible and
unambicious way