You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: source/concepts/faq.rst
+29-23Lines changed: 29 additions & 23 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,34 +1,40 @@
1
1
FAQ
2
2
###
3
3
4
-
#. In a few words, how would you describe the Genesis platform?
4
+
#. In a few words, how would you describe |platform|?
5
5
6
6
- A blockchain platform, designed to build digital ecosystems on the basis of an integrated application development environment with a multi-level system for the management of access rights to data, interfaces and smart contracts.
7
7
8
-
#. Does the Genesis platform work on the Bitcoin, Ethereum, or some other blockchain?
8
+
#. Does |platform| platform work on the Bitcoin, Ethereum, or some other blockchain?
9
9
10
-
- No, the Genesis platform is built on the basis of being its own original blockchain.
10
+
- No, |platform| is built on the basis of being its own original blockchain.
11
11
12
-
#. What are the main differences between the Genesis platform and other public blockchain platforms with built-in mechanisms for the execution of smart contracts, such as Ethereum, Qtum, and those still being designed, including Tezos and EOS?
12
+
#. What are the main differences between |platform| and other public blockchain platforms with built-in mechanisms for the execution of smart contracts, such as Ethereum, Qtum, and those still being designed, including Tezos and EOS?
13
13
14
-
- The Genesis platform features unique functions that cannot be found in the aforementioned blockchain platforms:
14
+
- |platform| features unique functions that cannot be found in the aforementioned blockchain platforms:
15
15
16
-
- Integrated application development environment implemented in a single client software;
16
+
- Integrated application development environment implemented in a single client software;
17
17
18
-
- Specialized template language for the design of interfaces, harmonized with the contract-building language;
18
+
- Specialized template language for the design of interfaces, harmonized with the contract-building language;
19
19
20
-
- Multi-level system for the management of access rights to data, contracts, and interfaces where rights can be granted to persons, member roles, and contracts;
20
+
- Multi-level system for the management of access rights to data, contracts, and interfaces where rights can be granted to persons, member roles, and contracts;
21
21
22
-
- Ecosystems – autonomous software environments for the creation of blockchain applications and user interactions with them;
22
+
- Ecosystems – autonomous software environments for the creation of blockchain applications and user interactions with them;
23
23
24
-
- Legal system – a set of regulations, codified in smart laws (specialized smart contracts), which regulate relations between the platform users, define the protocol parameters changing procedures, that are used to solve problems.
24
+
- Legal system – a set of regulations, codified in smart laws (specialized smart contracts), which regulate relations between the platform users, define the protocol parameters changing procedures, that are used to solve problems.
25
25
26
-
#. Does the Genesis platform have its own cryptocurrency?
26
+
#. Does |platform| have its own cryptocurrency?
27
27
28
-
- No, the Genesis platform does not have any cryptocurrencies.
28
+
.. ifconfig:: if_project in ('genesis')
29
+
30
+
- No, |platform| does not have any cryptocurrencies.
31
+
32
+
.. ifconfig:: if_project in ('apla')
33
+
34
+
- Yes, |platform| uses its own tokens, APL.
29
35
30
36
#. What is a validating node?
31
-
37
+
32
38
- A validating node is a network node that is authorized to check transactions and create blocks.
33
39
34
40
#. Who can maintain a validating node?
@@ -37,7 +43,7 @@ FAQ
37
43
38
44
#. What are platform ecosystems?
39
45
40
-
- Ecosystems are virtually autonomous software environments for the creation of blockchain applications and the user operations within them.
46
+
- Ecosystems are virtually autonomous software environments for the creation of blockchain applications and the user operations within them.
41
47
42
48
#. Who can create an ecosystem?
43
49
@@ -57,13 +63,13 @@ FAQ
57
63
58
64
#. Which programming language is used for the creation of applications?
59
65
60
-
- Contracts are written using the Simvolio language, which was developed by the platform team (see contract language description).
66
+
- Contracts are written using the Simvolio language, which was developed by the platform team (see contract language description).
61
67
62
-
- Interfaces are written using Protypo – an original interface template language (see template language description).
68
+
- Interfaces are written using Protypo – an original interface template language (see template language description).
63
69
64
70
#. Which software is used for creating applications and user interaction with them?
65
71
66
-
- Applications are written and executed in Molis – the single software client; no other software is required.
72
+
- Applications are written and executed in Molis – the single software client; no other software is required.
67
73
68
74
#. Can platform contracts access data using third-party API interfaces?
69
75
@@ -123,13 +129,13 @@ FAQ
123
129
124
130
#. Who pays for the operation of applications?
125
131
126
-
- An account (binding account), which the tokens for payment of resources are debited from, is set by the contract creator on its activation. It can be defined using ecosystem's smart laws whether or not the ecosystem members will pay for work with the application, and if yes, than what way of payment it will be (contributions or otherwise).
132
+
- An account (binding account), which the tokens for payment of resources are debited from, is set by the contract creator on its activation. It can be defined using ecosystem's smart laws whether or not the ecosystem members will pay for work with the application, and if yes, than what way of payment it will be (contributions or otherwise).
127
133
128
134
#. How are applications within ecosystems protected from exploit of their vulnerabilities?
129
135
130
136
- The platform team understands that there is no way to completely avoid mistakes in the program code of applications, especially given that applications can be written by any user. That's why we decided to create a mechanism that eliminates the consequences of vulnerability exploitation. The platform has a legal system (a set of smart laws), that allow for stopping the operation of an attacking application and make a number of transactions for restoring to the status quo. The rights to execute such contracts and voting procedures to grant these rights are defined in the smart laws of the platform's legal system.
131
137
132
-
#. Which new functions are planned to be implemented in the Genesis platform in the future?
138
+
#. Which new functions are planned to be implemented in |platform| in the future?
133
139
134
140
- Visual interface designer,
135
141
@@ -147,14 +153,14 @@ FAQ
147
153
148
154
- Semantic reference (ontology) for the unification of operations within the data in the platform.
149
155
150
-
#. Are there any proofs of the Genesis platform's operability?
156
+
#. Are there any proofs of |platform| operability?
151
157
152
158
- A number of proof of concept projects have been implemented on the platform during the last few months: a polling and voting system for a political party (Netherlands), new businesses registration (UAE), trading financial instruments (Luxembourg), register of property (India), and a contracts management system (UAE).
153
159
154
-
#. Does the Genesis platform have any obvious drawbacks?
160
+
#. Does |platform| have any obvious drawbacks?
155
161
156
-
- The biggest drawback of the platform, compared to, say, Ethereum, is that Genesis platform is just in the launch mode. But this drawback will transform into a big advantage over time.
162
+
- The biggest drawback of the platform, compared to, say, Ethereum, is that |platform| is just in the launch mode. But this drawback will transform into a big advantage over time.
157
163
158
-
#. What does the future of the Genesis platform look like?
164
+
#. What does the future of |platform| look like?
159
165
160
166
- The Genesis platform was designed based on the assumption that the full effect of blockchain technology can only be achieved when all activities, operations, registers and contracts are on the same blockchain network. Just as there can't be many co-existing Internets, there ultimately can't be many co-existing blockchain networks. We see the Genesis platform as a unified platform, which in the future will run the operations of all governments in the world.
Desync_monitor is a special tool that allows to verify that the databases on specified nodes are synchronized.
5
5
6
-
The tool can work as a daemon process or can be launched to perform a one-time check.
6
+
The tool can work as a daemon process or can be launched to perform a one-time check.
7
7
8
8
The tool's operation principle is based on the following:
9
9
10
-
#. Each block contains the hash of all changes made by all transactions in the block. The specified nodes are requested to provide the ID of their last common block.
10
+
#. Each block contains the hash of all changes made by all transactions in the block. The specified nodes are requested to provide the ID of their last common block.
11
11
12
-
#. A block with this ID is then requested from all nodes, and the aforementioned hash is compared.
12
+
#. A block with this ID is then requested from all nodes, and the aforementioned hash is compared.
13
13
14
14
#. If the hash differs, a synchronization error message is sent to the email address specified in the command.
15
15
@@ -23,37 +23,37 @@ The tool is located in ``tools/desync_monitor/``.
23
23
Command-prompt flags
24
24
====================
25
25
26
-
The following flags can be used from the command prompt:
26
+
The following flags can be used from the command prompt:
27
27
28
-
* **confPath**–path to the configuration file. By default – config.toml.
28
+
* **confPath**–path to the configuration file. By default – config.toml.
29
29
30
-
* **nodesList**–a list of nodes to request blocks from, separated by commas. By default – 127.0.0.1:7079.
30
+
* **nodesList**–a list of nodes to request blocks from, separated by commas. By default – 127.0.0.1:7079.
31
31
32
-
* **daemonMode**–launch as a daemon process; should be used in case the verification is required every N seconds. This flag is set to false by default.
32
+
* **daemonMode**–launch as a daemon process; should be used in case the verification is required every N seconds. This flag is set to false by default.
33
33
34
-
* **queryingPeriod**–if the tool is launched as a daemon process, this parameter sets the time interval between checks (in seconds). By default – 1 second.
34
+
* **queryingPeriod**–if the tool is launched as a daemon process, this parameter sets the time interval between checks (in seconds). By default – 1 second.
35
35
36
-
* **alertMessageTo**–an email address to which the synchronization error alerts will be sent. By default – [email protected].
36
+
* **alertMessageTo**–an email address to which the synchronization error alerts will be sent. By default – [email protected].
37
37
38
-
* **alertMessageSubj**–message subject to put in the alert message. By default – problem with nodes synchronization.
38
+
* **alertMessageSubj**–message subject to put in the alert message. By default – problem with nodes synchronization.
39
39
40
-
* **alertMessageFrom**–address from which the message will be sent. By default – [email protected].
40
+
* **alertMessageFrom**–address from which the message will be sent. By default – [email protected].
41
41
42
-
* **smtpHost**–SMTP server, which will be used to send the email message. By default – "".
42
+
* **smtpHost**–SMTP server, which will be used to send the email message. By default – "".
43
43
44
-
* **smtpPort**–SMTP server port, which will be used to send the email message. By default – 25.
44
+
* **smtpPort**–SMTP server port, which will be used to send the email message. By default – 25.
45
45
46
-
* **smtpUsername**–SMTP server username. By default – "".
46
+
* **smtpUsername**–SMTP server username. By default – "".
47
47
48
-
* **smtpPassword**–SMTP server password. By default – "".
48
+
* **smtpPassword**–SMTP server password. By default – "".
49
49
50
50
51
51
Configuration
52
52
=============
53
53
54
-
The tool uses a configuration file in the toml format.
54
+
The tool uses a configuration file in the toml format.
55
55
56
-
By default, it looks for the config.toml file in the folder from which the binary was launched.
56
+
By default, it looks for the config.toml file in the folder from which the binary was launched.
57
57
58
58
The file path can be changed using the configPath flag.
59
59
@@ -82,37 +82,40 @@ The file path can be changed using the configPath flag.
82
82
nodes_list
83
83
----------
84
84
85
-
* **nodes_list**–list of nodes (hosts) to request information from.
85
+
* **nodes_list**–list of nodes (hosts) to request information from.
86
86
87
87
88
88
[daemon]
89
89
--------
90
90
91
91
Daemon mode configuration.
92
92
93
-
* **daemon_mode**–tells the tool to work as a daemon process and perform synchronization checks.
93
+
* **daemon_mode**–tells the tool to work as a daemon process and perform synchronization checks.
94
94
95
-
* **querying_period**–time interval between synchronization checks.
95
+
* **querying_period**–time interval between synchronization checks.
96
96
97
97
98
98
[alert_message]
99
99
---------------
100
100
101
101
Alert message parameters.
102
102
103
-
* **to**–address to which the synchronization error alert messages will be sent.
103
+
* **to**–address to which the synchronization error alert messages will be sent.
104
104
105
-
* **subject**–message subject.
105
+
* **subject**–message subject.
106
106
107
-
* **from**–sender.
107
+
* **from**–sender.
108
108
109
109
110
110
[smtp]
111
111
------
112
112
113
113
Parameters of the SMTP server, which will be used to send synchronization error messages.
114
114
115
-
* **host**–SMTP server, which will be used to send the email messages.
116
-
* **port**–SMTP server port, which will be used to send the email messages.
117
-
* **username**–SMTP server username.
118
-
* **password**–SMTP server password.
115
+
* **host**–SMTP server, which will be used to send the email messages.
116
+
117
+
* **port**–SMTP server port, which will be used to send the email messages.
0 commit comments