@@ -20,7 +20,7 @@ This is the default Gossamer execution method, which invokes the `gossamerAction
20
20
blockchain client are [ described below in the Client Components section] ( #client-components ) .
21
21
22
22
- ` --basepath ` - the path to the directory where Gossamer will store its data
23
- - ` --chain ` - specifies the [ chain configuration] ( ../../chain ) that the
23
+ - ` --chain ` - specifies the [ chain configuration] ( ../../internal/ chain ) that the
24
24
[ Gossamer host node] ( https://chainsafe.github.io/gossamer/getting-started/overview/host-architecture/ ) should load
25
25
- ` --key ` - specifies a test keyring account to use (e.g. ` --key=alice ` )
26
26
- ` --log ` - supports levels ` crit ` (silent), ` error ` , ` warn ` , ` info ` , ` debug ` , and ` trce ` (detailed), default is ` info `
@@ -39,7 +39,7 @@ This subcommand accepts a genesis configuration file and uses it to initialise t
39
39
The ` account ` subcommand provides the user with capabilities related to generating and using ` ed25519 ` , ` secp256k1 ` , and
40
40
` sr25519 ` [ account keys] ( https://wiki.polkadot.network/docs/learn-keys ) , and managing the keys present in the
41
41
[ Gossamer keystore] ( #keystore ) . The ` accountAction ` function is defined in [ account.go] ( account.go ) ; it is an interface
42
- to the capabilities defined in the [ ` lib/crypto ` ] ( ../../lib/crypto ) and [ ` lib/keystore ` ] ( ../../lib/keystore ) packages.
42
+ to the capabilities defined in the [ ` lib/crypto ` ] ( ../../internal/ lib/crypto ) and [ ` lib/keystore ` ] ( ../../internal /lib/keystore ) packages.
43
43
This subcommand provides capabilities that are similar to
44
44
[ Parity's Subkey utility] ( https://docs.substrate.io/v3/tools/subkey ) .
45
45
@@ -68,7 +68,7 @@ in [`main.go`](main.go).
68
68
69
69
### Import State Subcommand
70
70
71
- The ` import-state ` subcommand allows a user to seed [ Gossamer storage] ( ../../dot/state ) with key-value pairs in the form
71
+ The ` import-state ` subcommand allows a user to seed [ Gossamer storage] ( ../../internal/ dot/state ) with key-value pairs in the form
72
72
of a JSON file. The input for this subcommand can be retrieved from
73
73
[ the ` state_getPairs ` RPC endpoint] ( https://github.com/w3f/PSPs/blob/master/PSPs/drafts/psp-6.md#1114-state_getpairs ) .
74
74
The ` importStateAction ` function is defined in [ ` main.go ` ] ( main.go ) .
@@ -86,7 +86,7 @@ The `importStateAction` function is defined in [`main.go`](main.go).
86
86
The ` export ` subcommand transforms a genesis configuration and Gossamer state into a TOML configuration file. This
87
87
subcommand invokes the ` exportAction ` function defined in [ ` export.go ` ] ( export.go ) .
88
88
89
- - ` --config ` - path to a TOML configuration file (e.g. those defined in [ the ` chain ` directory] ( ../../chain ) )
89
+ - ` --config ` - path to a TOML configuration file (e.g. those defined in [ the ` chain ` directory] ( ../../internal/ chain ) )
90
90
- ` --basepath ` - path to the Gossamer data directory that defines the state to export
91
91
92
92
## Client Components
@@ -96,8 +96,8 @@ In its default method of execution, Gossamer orchestrates a number of modular se
96
96
a blockchain network. Alongside these services, Gossamer manages [ a keystore] ( #keystore ) , [ a runtime] ( #runtime ) , and
97
97
[ monitoring utilities] ( #monitoring ) , all of which are described in greater detail below. The entry point to the Gossamer
98
98
blockchain client capabilities is the ` gossamerAction ` function that is defined in [ main.go] ( main.go ) , which in turn
99
- invokes the ` NewNode ` function in [ dot/node.go] ( ../../dot/node.go ) . ` NewNode ` calls into functions that are defined in
100
- [ dot/services.go] ( ../../dot/services.go ) and starts the services that power a Gossamer node.
99
+ invokes the ` NewNode ` function in [ dot/node.go] ( ../../internal/ dot/node.go ) . ` NewNode ` calls into functions that are defined in
100
+ [ dot/services.go] ( ../../internal/ dot/services.go ) and starts the services that power a Gossamer node.
101
101
102
102
### Services & Capabilities
103
103
@@ -108,60 +108,60 @@ What follows is a list that describes the services and capabilities that inform
108
108
This service is a wrapper around an instance of [ ` chaindb ` ] ( https://github.com/ChainSafe/chaindb ) , a key-value database
109
109
that is built on top of [ BadgerDB] ( https://github.com/dgraph-io/badger ) from [ Dgraph] ( https://dgraph.io/ ) . The state
110
110
service provides storage capabilities for the other Gossamer services - each service is assigned a prefix that is added
111
- to its storage keys. The state service is defined in [ dot/state/service.go] ( ../../dot/state/service.go ) .
111
+ to its storage keys. The state service is defined in [ dot/state/service.go] ( ../../internal/ dot/state/service.go ) .
112
112
113
113
#### Network
114
114
115
- The network service, which is defined in [ dot/network/service.go] ( ../../dot/network/service.go ) , is built on top of
115
+ The network service, which is defined in [ dot/network/service.go] ( ../../internal/ dot/network/service.go ) , is built on top of
116
116
[ the Go implementation] ( https://github.com/libp2p/go-libp2p ) of [ the ` libp2p ` protocol] ( https://libp2p.io/ ) . This
117
117
service manages a ` libp2p ` "host", a peer-to-peer networking term for a network participant that is providing both
118
118
client _ and_ server capabilities to a peer-to-peer network. Gossamer's network service manages the discovery of other
119
119
hosts as well as the connections with these hosts that allow Gossamer to communicate with its network peers.
120
120
121
121
#### Digest Handler
122
122
123
- The digest handler ([ dot/digest/digest.go] ( ../../dot/digest/digest.go ) ) manages the verification of the
123
+ The digest handler ([ dot/digest/digest.go] ( ../../internal/ dot/digest/digest.go ) ) manages the verification of the
124
124
[ digests] ( https://docs.substrate.io/v3/getting-started/glossary/#digest ) that are present in block headers.
125
125
126
126
#### Consensus
127
127
128
128
The BABE and GRANDPA services work together to provide Gossamer with its
129
129
[ hybrid consensus] ( https://wiki.polkadot.network/docs/learn-consensus#hybrid-consensus ) capabilities. The term "hybrid
130
130
consensus" refers to the fact that block _ production_ is decoupled from block _ finalisation_ . Block production is
131
- handled by the BABE service, which is defined in [ lib/babe/babe.go] ( ../../lib/babe/babe.go ) ; block finalisation is
132
- handled by the GRANDPA service, which is defined in [ lib/grandpa/grandpa.go] ( ../../lib/grandpa/grandpa.go ) .
131
+ handled by the BABE service, which is defined in [ lib/babe/babe.go] ( ../../internal/ lib/babe/babe.go ) ; block finalisation is
132
+ handled by the GRANDPA service, which is defined in [ lib/grandpa/grandpa.go] ( ../../internal/ lib/grandpa/grandpa.go ) .
133
133
134
134
#### Sync
135
135
136
136
This service is concerned with keeping Gossamer in sync with a blockchain - it implements a "bootstrap" mode, to
137
137
download and verify blocks that are part of an existing chain's history, and a "tip-syncing" mode that manages the
138
138
multiple candidate forks that may exist at the head of a live chain. The sync service makes use of
139
- [ a block verification utility] ( ../../lib/babe/verify.go ) that implements BABE logic and is used by Gossamer to verify
139
+ [ a block verification utility] ( ../../internal/ lib/babe/verify.go ) that implements BABE logic and is used by Gossamer to verify
140
140
blocks that were produced by other other nodes in the network. The sync service is defined in
141
- [ dot/sync/syncer.go] ( ../../dot/sync/syncer.go ) .
141
+ [ dot/sync/syncer.go] ( ../../internal/ dot/sync/syncer.go ) .
142
142
143
143
#### RPC
144
144
145
- This service, which is defined in [ dot/rpc/service.go] ( ../../dot/rpc/service.go ) , exposes a JSON-RPC interface that is
145
+ This service, which is defined in [ dot/rpc/service.go] ( ../../internal/ dot/rpc/service.go ) , exposes a JSON-RPC interface that is
146
146
used by client applications like [ Polkadot JS Apps UI] ( https://polkadot.js.org/apps/ ) . The RPC interface is used to
147
147
interact with Gossamer to perform administrative tasks such as key management, as well as for interacting with the
148
148
runtime by querying storage and submitting transactions, and inspecting the chain's history.
149
149
150
150
#### System
151
151
152
- The system service is defined in [ dot/system/service.go] ( ../../dot/system/service.go ) and exposes metadata about the
152
+ The system service is defined in [ dot/system/service.go] ( ../../internal/ dot/system/service.go ) and exposes metadata about the
153
153
Gossamer system, such as the names and versions of the protocols that it implements.
154
154
155
155
#### Core
156
156
157
- As its name implies, the core service ([ dot/core/service.go] ( ../../dot/core/service.go ) ) encapsulates a range of
157
+ As its name implies, the core service ([ dot/core/service.go] ( ../../internal/ dot/core/service.go ) ) encapsulates a range of
158
158
capabilities that are central to the functioning of a Gossamer node. In general, the core service is a type of
159
159
dispatcher that coordinates interactions between services, e.g. writing blocks to the database, reloading
160
160
[ the runtime] ( #runtime ) when its definition is updated, etc.
161
161
162
162
### Keystore
163
163
164
- The Gossamer keystore ([ lib/keystore] ( ../../lib/keystore ) ) is used for managing the public/private cryptographic key
164
+ The Gossamer keystore ([ lib/keystore] ( ../../internal/ lib/keystore ) ) is used for managing the public/private cryptographic key
165
165
pairs that are used for participating in a blockchain network. Public keys are used to identify network participants;
166
166
network participants use their private keys to sign messages in order to authorise privileged actions. In addition to
167
167
informing the Gossamer blockchain client capabilities, the Gossamer keystore is accessible by way of the ` account `
@@ -177,16 +177,16 @@ subcommand. The Gossamer keystore manages a number of key types, some of which a
177
177
178
178
In addition to the above-described services, Gossamer hosts a Wasm execution environment that is used to manage an
179
179
upgradeable blockchain runtime. The runtime must be implemented in Wasm, and must expose an interface that is specified
180
- in [ lib/runtime/interface.go] ( ../../lib/runtime/interface.go ) . The runtime defines the blockchain's state transition
180
+ in [ lib/runtime/interface.go] ( ../../internal/ lib/runtime/interface.go ) . The runtime defines the blockchain's state transition
181
181
function, and the various Gossamer services consume this capability in order to author blocks, as well as to verify
182
182
blocks that were authored by network peers. The runtime is dependent on a
183
183
[ Wasm host interface] ( https://docs.wasmer.io/integrations/examples/host-functions ) , which Gossamer implements and is
184
- defined in [ lib/runtime/wasmer/exports.go] ( ../../lib/runtime/wasmer/exports.go ) .
184
+ defined in [ lib/runtime/wasmer/exports.go] ( ../../internal/ lib/runtime/wasmer/exports.go ) .
185
185
186
186
### Monitoring
187
187
188
188
Gossamer publishes telemetry data and also includes an embedded Prometheus server that reports metrics. The metrics
189
- capabilities are defined in the [ dot/metrics] ( ../../dot/metrics ) package and build on
189
+ capabilities are defined in the [ dot/metrics] ( ../../internal/ dot/metrics ) package and build on
190
190
[ the metrics library that is included with Go Ethereum] ( https://github.com/ethereum/go-ethereum/blob/master/metrics/README.md ) .
191
191
The default port for Prometheus metrics is 9090, and Gossamer allows the user to configure this parameter with the
192
192
` --metrics-port ` command-line parameter. The Gossamer telemetry server publishes telemetry data that is compatible with
0 commit comments