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
The channel creation transaction needs a way to specify additional data
that is not otherwise reflected in the standard config. Still, it's
desirable to specify this information in a consistent way, so it should
be expressed using the same structures as the configuration.
This CR introduces the notion of the 'isolated_data' field to the
ConfigUpdate message. For now, the only consumer will be the RSCC seed
data information, which will be set to the key rscc_seed_data and will
be the bytes of a common.Config message.
Because we need to be able to be able to inspect this new config message
type, we need a way to differentiate channel config from resource
config. Thus, this CR also introduces a 'type' field to both the Config
message and the ConfigUpdate message.
Change-Id: Ida6283dbeeca466aafd9bc6d027ce46e1baee0c6
Signed-off-by: Jason Yellick <jyellick@us.ibm.com>
// ConfigType is an enumeration of possible types for the config. The type field in the config is
18
+
// an int32 for extensibility, but this enum type should generally be used to populate it
19
+
enumConfigType {
20
+
CHANNEL=0; // The original and default configuration type, defines parameters for the operation of a channel
21
+
RESOURCE=1; // Defines a set of resource names, and their mapping to policies which restrict access to those resources
22
+
}
23
+
27
24
// ConfigEnvelope is designed to contain _all_ configuration for a chain with no dependency
28
25
// on previous configuration transactions.
29
26
//
@@ -64,7 +61,8 @@ message ConfigPolicySchema {}
64
61
// Config represents the config for a particular channel
65
62
messageConfig {
66
63
uint64sequence=1;
67
-
ConfigGroupchannel_group=2;
64
+
ConfigGroupchannel_group=2; // channel_group is a bad name for this, it should be changed to root when API breakage is allowed
65
+
int32type=3;
68
66
}
69
67
70
68
messageConfigUpdateEnvelope {
@@ -82,9 +80,11 @@ message ConfigUpdateEnvelope {
82
80
// 4. Each policy is checked against the signatures from the ConfigUpdateEnvelope, any failing to verify are rejected
83
81
// 5. The write_set is applied to the Config and the ConfigGroupSchema verifies that the updates were legal
84
82
messageConfigUpdate {
85
-
stringchannel_id=1; // Which channel this config update is for
86
-
ConfigGroupread_set=2; // ReadSet explicitly lists the portion of the config which was read, this should be sparse with only Version set
87
-
ConfigGroupwrite_set=3; // WriteSet lists the portion of the config which was written, this should included updated Versions
83
+
stringchannel_id=1; // Which channel this config update is for
84
+
ConfigGroupread_set=2; // ReadSet explicitly lists the portion of the config which was read, this should be sparse with only Version set
85
+
ConfigGroupwrite_set=3; // WriteSet lists the portion of the config which was written, this should included updated Versions
86
+
int32type=4; // The type of config this update is intended for (usually a value from ConfigType enum) , must match the type in the Config message
87
+
map<string, bytes> isolated_data=5; // Data which is not to be reflected in the resulting Config, but is still needed for some other purpose. For instance, rscc_seed_data
88
88
}
89
89
90
90
// ConfigGroup is the hierarchical data structure for holding config
0 commit comments