From 961a3325edbccb55cbdbaad6e1d17177122aeeba Mon Sep 17 00:00:00 2001 From: Benjamin Bollen Date: Wed, 1 Jul 2015 16:29:15 +0100 Subject: [PATCH 01/12] initial commit --- ...pact-Unified-Structured-Data-on-Routing.md | 136 ++++++++++++++++++ 1 file changed, 136 insertions(+) create mode 100644 proposed/0000-Impact-Unified-Structured-Data-on-Routing.md diff --git a/proposed/0000-Impact-Unified-Structured-Data-on-Routing.md b/proposed/0000-Impact-Unified-Structured-Data-on-Routing.md new file mode 100644 index 0000000..b2cec27 --- /dev/null +++ b/proposed/0000-Impact-Unified-Structured-Data-on-Routing.md @@ -0,0 +1,136 @@ +- Feature Name: impact_unified_structured_data_on_routing +- Type: Enhancement +- Related components: routing and sentinel +- Start Date: 30-06-2015 +- RFC PR: (leave this empty) +- Issue number: (leave this empty) + +# Summary + +[RFC Unified Structured Data](https://github.com/dirvine/rfcs/blob/unified-structured-data/proposed/0000-Unified-structured-data.md) introduces `StructuredData` as a fundamental type for the network. +This RFC explores in more detail the implications for applying this change for routing +and sentinel library. + +# Motivation + +For the motivation on introducing `Unified Structured Data` we refer back to +the parent RFC. The motivation for the current RFC is to establish a collective +understanding of the changes needed for routing and sentinel to +implementing the parent RFC. This RFC explicitly excludes the intend to change +the design of the actual `StructuredData` and any such discussions should be +posted on the parent RFC. + +# Detailed design + +For the design of the actual `StructuredData` we again refer to the parent RFC. + +## Types +In routing three new fundamental types will be introduced `PlainData`, +`ImmutableData`, `StructuredData` + +### Plain data + +```rust +struct PlainData { + key : NameType, + value : Vec +} +``` + +Routing will not perform any additional validation on the PlainData type. +Default routing behaviour applies to this type, which is briefly recapitulated +below. + +### Immutable data + +``` rust +struct ImmutableData { + tag_type : u8, + value : Vec +} + +impl ImmutableData { + pub fn new(tag_type: u8, value : Vec) -> ImmutableData {} + + pub fn name(&self) -> NameType { + (tag_type + 1) Hash iterations of self.value + } + + pub fn content(&self) -> &[u8] { + &self.value[..] + } +} +``` + +Routing considers `ImmutableData` valid when a requested `name` equals +`immutable_data.name()`. + +### Structured data + +We repeat the structure as defined in the parent RFC + +``` rust +struct StructuredData { + tag_type : [u8; 8], + identifier : NameType, + data : Vec, + owner_keys : Vec, + version : u64, + previous_owner_keys : vec + signature : Vec +} + +impl StructuredData { + pub fn new( + tag_type: u8, + identifier : NameType, + data : Vec, + owner_keys : Vec, + version : u64, + previous_owner_keys : vec + signature : Vec) -> Result { + // validate: + // 0. total size <= 100 kB + // 1. must always be owned + // 2. on version == 0, no signatures needed + // 3. if previous owners set: check signatures with majority + // of their keys + // 4. if no previous owners: check signatures with majority + // of their keys + construct!() + } + + pub fn name(&self) -> NameType { + SHA512(tag_type + identifier) + } + +} +``` + +- `data` Routing does not parse the `data` field; it is always considered +as serialised bytes. +- `version` Routing does not (currently) attempt to resolve concurreny issues; +as such `version` is unused at routing. Additionally routing has no knowledge +of the previously stored valid version. The version number is for the user. +- `tag_type` Routing does not attach meaning to the 8 byte `tag_type` and treats +all tag_types equal. + + + +### Standard routing behaviour + + + + MessageAction::SendOn + +# Drawbacks + +Why should we *not* do this? + +# Alternatives + +What other designs have been considered? What is the impact of not doing this? + +# Unresolved questions + +What parts of the design are still to be done? From e39422b917c64d474754ac66e08b77ce168ec092 Mon Sep 17 00:00:00 2001 From: Benjamin Bollen Date: Wed, 1 Jul 2015 16:38:06 +0100 Subject: [PATCH 02/12] add_signature --- proposed/0000-Impact-Unified-Structured-Data-on-Routing.md | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/proposed/0000-Impact-Unified-Structured-Data-on-Routing.md b/proposed/0000-Impact-Unified-Structured-Data-on-Routing.md index b2cec27..ec3d185 100644 --- a/proposed/0000-Impact-Unified-Structured-Data-on-Routing.md +++ b/proposed/0000-Impact-Unified-Structured-Data-on-Routing.md @@ -56,6 +56,7 @@ impl ImmutableData { (tag_type + 1) Hash iterations of self.value } + // add lifetime if needed pub fn content(&self) -> &[u8] { &self.value[..] } @@ -82,7 +83,7 @@ struct StructuredData { impl StructuredData { pub fn new( - tag_type: u8, + tag_type : [u8; 8], identifier : NameType, data : Vec, owner_keys : Vec, @@ -104,6 +105,9 @@ impl StructuredData { SHA512(tag_type + identifier) } + pub fn content(&self) -> &[u8] {} + + pub fn add_signature(&mut self, private_sign_key : &crypto::sign::SecretKey) {} } ``` From 2a010c56560e71f51a44f43151b29a0288edfc82 Mon Sep 17 00:00:00 2001 From: Benjamin Bollen Date: Wed, 1 Jul 2015 17:23:21 +0100 Subject: [PATCH 03/12] routing_message --- ...pact-Unified-Structured-Data-on-Routing.md | 26 +++++++++++++++++++ 1 file changed, 26 insertions(+) diff --git a/proposed/0000-Impact-Unified-Structured-Data-on-Routing.md b/proposed/0000-Impact-Unified-Structured-Data-on-Routing.md index ec3d185..66849ec 100644 --- a/proposed/0000-Impact-Unified-Structured-Data-on-Routing.md +++ b/proposed/0000-Impact-Unified-Structured-Data-on-Routing.md @@ -118,8 +118,34 @@ as such `version` is unused at routing. Additionally routing has no knowledge of the previously stored valid version. The version number is for the user. - `tag_type` Routing does not attach meaning to the 8 byte `tag_type` and treats all tag_types equal. +- the signature should sign in order `data`, `version`, `owner_keys` and +`previous_owner_keys` +## Impact on routing message +Currently `RoutingMessage` has the following declaration with +an obligatory signature from the `Header::Source::fromNode` +```rust +pub struct RoutingMessage { + pub message_type: MessageTypeTag, + pub message_header: message_header::MessageHeader, + pub serialised_body: Vec, + pub signature : types::Signature +} +``` + +As every client connects to the network over a relocated relay node, +we can keep this obligatory signature and have it signed by the relay node. +This puts responsibility on the relay node when injecting client messages in +the network, and keeps consistency that the from_node on the network is always +the id of a relocated node, not the hash of a 32byte client PublicKey. + +RoutingClient will sign RoutingMessages with the generic unrelocated Id +it self-generates on construction. This generic Id is unrelated to the keys +for signing ownership of structured data; it is purely and internally used +by routing to identify client-relay connections, per session. + +## ### Standard routing behaviour From 6f402dc2cec4630d8df73e9407529ab7a4df3c4c Mon Sep 17 00:00:00 2001 From: Benjamin Bollen Date: Wed, 1 Jul 2015 23:42:38 +0100 Subject: [PATCH 04/12] New MessageTypes --- ...pact-Unified-Structured-Data-on-Routing.md | 23 ++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) diff --git a/proposed/0000-Impact-Unified-Structured-Data-on-Routing.md b/proposed/0000-Impact-Unified-Structured-Data-on-Routing.md index 66849ec..9b1ea80 100644 --- a/proposed/0000-Impact-Unified-Structured-Data-on-Routing.md +++ b/proposed/0000-Impact-Unified-Structured-Data-on-Routing.md @@ -145,7 +145,28 @@ it self-generates on construction. This generic Id is unrelated to the keys for signing ownership of structured data; it is purely and internally used by routing to identify client-relay connections, per session. -## +## Reducing MessageTypes + +Routing can reduce to the following message types; the main motivation +is to simplify the message handlers. + +``` rust +pub enum MessageTypeTag { + ConnectRequest, + ConnectResponse, + ConnectSuccess,* + FindGroup, + FindGroupResponse, + GetGroupKey, + GetGroupKeyResponse, + PutPublicId, + PutPublicIdResponse, + ActionRequest, + ActionResponse, + Refresh, + Unknown, +} +``` ### Standard routing behaviour From 4d0cfb69f6c0b7ae2e806e1f63a0edce96f5061b Mon Sep 17 00:00:00 2001 From: Benjamin Bollen Date: Thu, 2 Jul 2015 11:54:39 +0100 Subject: [PATCH 05/12] is_valid_successor --- ...0-Impact-Unified-Structured-Data-on-Routing.md | 15 +++++++++++---- 1 file changed, 11 insertions(+), 4 deletions(-) diff --git a/proposed/0000-Impact-Unified-Structured-Data-on-Routing.md b/proposed/0000-Impact-Unified-Structured-Data-on-Routing.md index 9b1ea80..99473ff 100644 --- a/proposed/0000-Impact-Unified-Structured-Data-on-Routing.md +++ b/proposed/0000-Impact-Unified-Structured-Data-on-Routing.md @@ -72,7 +72,7 @@ We repeat the structure as defined in the parent RFC ``` rust struct StructuredData { - tag_type : [u8; 8], + tag_type : u64, identifier : NameType, data : Vec, owner_keys : Vec, @@ -83,7 +83,7 @@ struct StructuredData { impl StructuredData { pub fn new( - tag_type : [u8; 8], + tag_type : u64, identifier : NameType, data : Vec, owner_keys : Vec, @@ -108,6 +108,10 @@ impl StructuredData { pub fn content(&self) -> &[u8] {} pub fn add_signature(&mut self, private_sign_key : &crypto::sign::SecretKey) {} + + pub fn is_valid_successor(&self, successor: &StructuredData) -> bool { + // see detailed discussion of logic below + } } ``` @@ -118,8 +122,11 @@ as such `version` is unused at routing. Additionally routing has no knowledge of the previously stored valid version. The version number is for the user. - `tag_type` Routing does not attach meaning to the 8 byte `tag_type` and treats all tag_types equal. -- the signature should sign in order `data`, `version`, `owner_keys` and -`previous_owner_keys` +- the signature should sign in bytes that are concatenated +in the following order: `data`, `version`, `owner_keys` and +`previous_owner_keys` - purely as a matter of convention. + +Corresponding `get` functions for all data fields are implied. ## Impact on routing message From 88fb3a0891f974b67711436fed40d5cc564551a1 Mon Sep 17 00:00:00 2001 From: Benjamin Bollen Date: Thu, 2 Jul 2015 13:58:48 +0100 Subject: [PATCH 06/12] validation logic efficiency consideration --- ...pact-Unified-Structured-Data-on-Routing.md | 41 +++++++++++++++++++ 1 file changed, 41 insertions(+) diff --git a/proposed/0000-Impact-Unified-Structured-Data-on-Routing.md b/proposed/0000-Impact-Unified-Structured-Data-on-Routing.md index 99473ff..c9a7563 100644 --- a/proposed/0000-Impact-Unified-Structured-Data-on-Routing.md +++ b/proposed/0000-Impact-Unified-Structured-Data-on-Routing.md @@ -128,6 +128,47 @@ in the following order: `data`, `version`, `owner_keys` and Corresponding `get` functions for all data fields are implied. +#### logic for valid succession of structured data + +The structured data is recursively validated strictly on the preceding version. +That is the validity of a `StructuredData` of version `n` can only depend +on the validity of the same `StructuredData` of version `n-1`. Here "same" +means "have the same name". For `StructuredData` of version `n = 0` the +validity is `true` (and hence ClientManagers can charge an account to create +new valid `StructuredData_v0`). + +The version number must strictly increase by one. +All structured data must be owned; transfer of ownership is discussed below. +A majority is 50%, as outlined in the parent RFC + +**case : previous owner field is empty** + +An empty `previous_owner_keys` vector implies that the `owner_keys` +of version `n` must match the `owner_keys` of version `n-1`. +The `previous_owner_keys` of version `n-1` is ignored. +In this case no transfer of ownership is executed. The signatures must +be validatable with a majority of the keys of the current owners of version `n`. + +**case : previous owner field is not empty** + +A non-empty `previous_owner_keys` vector implies that there is an intent to +transfer ownership. In this case the `previous_owner_keys` of version `n` +must match the `owner_keys` of version `n-1`. The signatures must be +validatable with a majority of the keys of `previous_owner_keys` of version `n`. + +#### efficiency consideration when validating the signatures + +As outlined above, a signed vector of public keys defines a fixed order of +the public keys that will be checked to validate the signatures (see above +on previous owners or not). On construction of a `StructuredData` +the `Vec` will be ordered to the fixed order defined by the +relevant `Vec`. + +Any validation effort will then in sequence iterate over the signatures, and +in sequence check the keys, starting from the same index. This is an +easy algorithm for minimizing the search for matching signatures. A better +algorithm can be suggested. + ## Impact on routing message Currently `RoutingMessage` has the following declaration with From 550942c8c840baf456a1f658b8d143832841238a Mon Sep 17 00:00:00 2001 From: Benjamin Bollen Date: Thu, 2 Jul 2015 14:45:57 +0100 Subject: [PATCH 07/12] Enum FundamentalData --- ...pact-Unified-Structured-Data-on-Routing.md | 31 +++++++++++++++++++ 1 file changed, 31 insertions(+) diff --git a/proposed/0000-Impact-Unified-Structured-Data-on-Routing.md b/proposed/0000-Impact-Unified-Structured-Data-on-Routing.md index c9a7563..bbffd94 100644 --- a/proposed/0000-Impact-Unified-Structured-Data-on-Routing.md +++ b/proposed/0000-Impact-Unified-Structured-Data-on-Routing.md @@ -216,6 +216,37 @@ pub enum MessageTypeTag { } ``` +Replacing `GetData`, `GetDataResponse`, `PutData`, `PutDataResponse`, +`Post`, `PostResponse`, `Delete`, `DeleteResponse` with `ActionRequest` +and `ActionResponse` will make the handling of messages more generic. +It is a worthwhile, but not a blocking improvement. + +We can gradually do this by implementing `Post` and `Delete` according to this +`Action` paradigm, and after the sprint revisit `Get` and `Put` after evaluation. + +``` rust +pub enum FundamentalData { + NoData, + Plain(PlainData), + Immutable(ImmutableData), + Structured(StructuredData) +} + +pub enum Action { + _Put, + _Get(NameAndTypeId), + Post, + Delete +} + +struct ActionRequest { + data : FundamentalData, + action : Action, +} +``` + +#### update NameAndTypeId + ### Standard routing behaviour From a60b570aaa2220b222e8c7bb632796d7e83bd20f Mon Sep 17 00:00:00 2001 From: Benjamin Bollen Date: Thu, 2 Jul 2015 15:17:19 +0100 Subject: [PATCH 08/12] UnifiedData --- ...pact-Unified-Structured-Data-on-Routing.md | 72 +++++++------------ 1 file changed, 24 insertions(+), 48 deletions(-) diff --git a/proposed/0000-Impact-Unified-Structured-Data-on-Routing.md b/proposed/0000-Impact-Unified-Structured-Data-on-Routing.md index bbffd94..9ca4927 100644 --- a/proposed/0000-Impact-Unified-Structured-Data-on-Routing.md +++ b/proposed/0000-Impact-Unified-Structured-Data-on-Routing.md @@ -193,74 +193,50 @@ it self-generates on construction. This generic Id is unrelated to the keys for signing ownership of structured data; it is purely and internally used by routing to identify client-relay connections, per session. -## Reducing MessageTypes +## Conservative approach to MessageTypes Routing can reduce to the following message types; the main motivation -is to simplify the message handlers. +is to simplify the message handlers. However, we will first go for +a conservative approach and extend the existing paradigm. -``` rust -pub enum MessageTypeTag { - ConnectRequest, - ConnectResponse, - ConnectSuccess,* - FindGroup, - FindGroupResponse, - GetGroupKey, - GetGroupKeyResponse, - PutPublicId, - PutPublicIdResponse, - ActionRequest, - ActionResponse, - Refresh, - Unknown, -} -``` +This requires updating `GetData`, `GetDataResponse`, `PutData`, `PutDataResponse`. +It leads to introducing `Post`, `PostResponse`, `Delete`, `DeleteResponse`. -Replacing `GetData`, `GetDataResponse`, `PutData`, `PutDataResponse`, -`Post`, `PostResponse`, `Delete`, `DeleteResponse` with `ActionRequest` -and `ActionResponse` will make the handling of messages more generic. -It is a worthwhile, but not a blocking improvement. - -We can gradually do this by implementing `Post` and `Delete` according to this -`Action` paradigm, and after the sprint revisit `Get` and `Put` after evaluation. +The corresponding handlers need to be updated/written, replacing `serialised_bytes` +with `UnifiedData`. ``` rust -pub enum FundamentalData { - NoData, - Plain(PlainData), - Immutable(ImmutableData), - Structured(StructuredData) -} - -pub enum Action { - _Put, - _Get(NameAndTypeId), - Post, - Delete -} - -struct ActionRequest { - data : FundamentalData, - action : Action, +pub enum UnifiedData { + PlainData, + ImmutableData(u8), + StructuredData(u64) } ``` -#### update NameAndTypeId - -### Standard routing behaviour +## also update with UnifiedData enumeration +This list is not exhaustive; all previously `serialised bytes` +need to be updated to a `UnifiedData`. - +- `NameTypeAndId` +- `MessageAction` +- `MethodCall` +- `RoutingMembrane::Put`, `RoutingMembrane::Get`, etc +- `RoutingClient::Put`, `RoutingClient::Get`, etc +- `NodeInterface` +- `ClientInterface` - MessageAction::SendOn # Drawbacks Why should we *not* do this? +(uncompleted) # Alternatives What other designs have been considered? What is the impact of not doing this? +(uncompleted) # Unresolved questions What parts of the design are still to be done? +(uncompleted) From 60104143fd24ba358e97d50849059bed9a992aa5 Mon Sep 17 00:00:00 2001 From: Benjamin Bollen Date: Thu, 2 Jul 2015 15:58:43 +0100 Subject: [PATCH 09/12] improve add_signature --- proposed/0000-Impact-Unified-Structured-Data-on-Routing.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/proposed/0000-Impact-Unified-Structured-Data-on-Routing.md b/proposed/0000-Impact-Unified-Structured-Data-on-Routing.md index 9ca4927..37d7148 100644 --- a/proposed/0000-Impact-Unified-Structured-Data-on-Routing.md +++ b/proposed/0000-Impact-Unified-Structured-Data-on-Routing.md @@ -107,7 +107,9 @@ impl StructuredData { pub fn content(&self) -> &[u8] {} - pub fn add_signature(&mut self, private_sign_key : &crypto::sign::SecretKey) {} + pub fn add_signature(&mut self, + private_sign_key : &crypto::sign::SecretKey, + public_sign_key: &crypto::sign::PublicKey) -> Result {} pub fn is_valid_successor(&self, successor: &StructuredData) -> bool { // see detailed discussion of logic below @@ -225,7 +227,6 @@ need to be updated to a `UnifiedData`. - `NodeInterface` - `ClientInterface` - # Drawbacks Why should we *not* do this? From 0a57f6b982150a37143307f8cd53a6b916ed8eb1 Mon Sep 17 00:00:00 2001 From: Benjamin Bollen Date: Mon, 5 Oct 2015 14:43:55 +0100 Subject: [PATCH 10/12] Addendum to Unified-Structured-Data --- active/0000-Unified-structured-data.md | 247 +++++++++++++++++++++++++ 1 file changed, 247 insertions(+) diff --git a/active/0000-Unified-structured-data.md b/active/0000-Unified-structured-data.md index 79d4d23..385b310 100644 --- a/active/0000-Unified-structured-data.md +++ b/active/0000-Unified-structured-data.md @@ -125,3 +125,250 @@ Status quo is an option and realistic. 1. Size of StructuredData packet, it would be nice if it were perhaps 512Bytes to have the best chance to fit into a single UDP packet, although not guaranteed. Means a payload after serialisation of only a few hundred bytes (maybe less) 2. Version conflicts or out of order updates, will upper layers handle this via a wait condition? + +-------------------------------------------------------------------------------- +# Addendum + +- Feature Name: impact_unified_structured_data_on_routing +- Type: Enhancement +- Related components: routing and sentinel +- Start Date: 30-06-2015 +- RFC PR: (leave this empty) +- Issue number: (leave this empty) + +# Summary + +[RFC Unified Structured Data](https://github.com/dirvine/rfcs/blob/unified-structured-data/proposed/0000-Unified-structured-data.md) introduces `StructuredData` as a fundamental type for the network. +This RFC explores in more detail the implications for applying this change for routing +and sentinel library. This is not the exact implementation as completed after Rust-3, but appended for reference. + +# Motivation + +For the motivation on introducing `Unified Structured Data` we refer back to +the parent RFC. The motivation for the current RFC is to establish a collective +understanding of the changes needed for routing and sentinel to +implementing the parent RFC. This RFC explicitly excludes the intend to change +the design of the actual `StructuredData` and any such discussions should be +posted on the parent RFC. + +# Detailed design + +For the design of the actual `StructuredData` we again refer to the parent RFC. + +## Types +In routing three new fundamental types will be introduced `PlainData`, +`ImmutableData`, `StructuredData` + +### Plain data + +```rust +struct PlainData { + key : NameType, + value : Vec +} +``` + +Routing will not perform any additional validation on the PlainData type. +Default routing behaviour applies to this type, which is briefly recapitulated +below. + +### Immutable data + +``` rust +struct ImmutableData { + tag_type : u8, + value : Vec +} + +impl ImmutableData { + pub fn new(tag_type: u8, value : Vec) -> ImmutableData {} + + pub fn name(&self) -> NameType { + (tag_type + 1) Hash iterations of self.value + } + + // add lifetime if needed + pub fn content(&self) -> &[u8] { + &self.value[..] + } +} +``` + +Routing considers `ImmutableData` valid when a requested `name` equals +`immutable_data.name()`. + +### Structured data + +We repeat the structure as defined in the parent RFC + +``` rust +struct StructuredData { + tag_type : u64, + identifier : NameType, + data : Vec, + owner_keys : Vec, + version : u64, + previous_owner_keys : vec + signature : Vec +} + +impl StructuredData { + pub fn new( + tag_type : u64, + identifier : NameType, + data : Vec, + owner_keys : Vec, + version : u64, + previous_owner_keys : vec + signature : Vec) -> Result { + // validate: + // 0. total size <= 100 kB + // 1. must always be owned + // 2. on version == 0, no signatures needed + // 3. if previous owners set: check signatures with majority + // of their keys + // 4. if no previous owners: check signatures with majority + // of their keys + construct!() + } + + pub fn name(&self) -> NameType { + SHA512(tag_type + identifier) + } + + pub fn content(&self) -> &[u8] {} + + pub fn add_signature(&mut self, + private_sign_key : &crypto::sign::SecretKey, + public_sign_key: &crypto::sign::PublicKey) -> Result {} + + pub fn is_valid_successor(&self, successor: &StructuredData) -> bool { + // see detailed discussion of logic below + } +} +``` + +- `data` Routing does not parse the `data` field; it is always considered +as serialised bytes. +- `version` Routing does not (currently) attempt to resolve concurreny issues; +as such `version` is unused at routing. Additionally routing has no knowledge +of the previously stored valid version. The version number is for the user. +- `tag_type` Routing does not attach meaning to the 8 byte `tag_type` and treats +all tag_types equal. +- the signature should sign in bytes that are concatenated +in the following order: `data`, `version`, `owner_keys` and +`previous_owner_keys` - purely as a matter of convention. + +Corresponding `get` functions for all data fields are implied. + +#### logic for valid succession of structured data + +The structured data is recursively validated strictly on the preceding version. +That is the validity of a `StructuredData` of version `n` can only depend +on the validity of the same `StructuredData` of version `n-1`. Here "same" +means "have the same name". For `StructuredData` of version `n = 0` the +validity is `true` (and hence ClientManagers can charge an account to create +new valid `StructuredData_v0`). + +The version number must strictly increase by one. +All structured data must be owned; transfer of ownership is discussed below. +A majority is 50%, as outlined in the parent RFC + +**case : previous owner field is empty** + +An empty `previous_owner_keys` vector implies that the `owner_keys` +of version `n` must match the `owner_keys` of version `n-1`. +The `previous_owner_keys` of version `n-1` is ignored. +In this case no transfer of ownership is executed. The signatures must +be validatable with a majority of the keys of the current owners of version `n`. + +**case : previous owner field is not empty** + +A non-empty `previous_owner_keys` vector implies that there is an intent to +transfer ownership. In this case the `previous_owner_keys` of version `n` +must match the `owner_keys` of version `n-1`. The signatures must be +validatable with a majority of the keys of `previous_owner_keys` of version `n`. + +#### efficiency consideration when validating the signatures + +As outlined above, a signed vector of public keys defines a fixed order of +the public keys that will be checked to validate the signatures (see above +on previous owners or not). On construction of a `StructuredData` +the `Vec` will be ordered to the fixed order defined by the +relevant `Vec`. + +Any validation effort will then in sequence iterate over the signatures, and +in sequence check the keys, starting from the same index. This is an +easy algorithm for minimizing the search for matching signatures. A better +algorithm can be suggested. + +## Impact on routing message + +Currently `RoutingMessage` has the following declaration with +an obligatory signature from the `Header::Source::fromNode` +```rust +pub struct RoutingMessage { + pub message_type: MessageTypeTag, + pub message_header: message_header::MessageHeader, + pub serialised_body: Vec, + pub signature : types::Signature +} +``` + +As every client connects to the network over a relocated relay node, +we can keep this obligatory signature and have it signed by the relay node. +This puts responsibility on the relay node when injecting client messages in +the network, and keeps consistency that the from_node on the network is always +the id of a relocated node, not the hash of a 32byte client PublicKey. + +RoutingClient will sign RoutingMessages with the generic unrelocated Id +it self-generates on construction. This generic Id is unrelated to the keys +for signing ownership of structured data; it is purely and internally used +by routing to identify client-relay connections, per session. + +## Conservative approach to MessageTypes + +Routing can reduce to the following message types; the main motivation +is to simplify the message handlers. However, we will first go for +a conservative approach and extend the existing paradigm. + +This requires updating `GetData`, `GetDataResponse`, `PutData`, `PutDataResponse`. +It leads to introducing `Post`, `PostResponse`, `Delete`, `DeleteResponse`. + +The corresponding handlers need to be updated/written, replacing `serialised_bytes` +with `UnifiedData`. + +``` rust +pub enum UnifiedData { + PlainData, + ImmutableData(u8), + StructuredData(u64) +} +``` + +## also update with UnifiedData enumeration +This list is not exhaustive; all previously `serialised bytes` +need to be updated to a `UnifiedData`. + +- `NameTypeAndId` +- `MessageAction` +- `MethodCall` +- `RoutingMembrane::Put`, `RoutingMembrane::Get`, etc +- `RoutingClient::Put`, `RoutingClient::Get`, etc +- `NodeInterface` +- `ClientInterface` + +# Drawbacks + +Why should we *not* do this? +(uncompleted) + +# Alternatives + +What other designs have been considered? What is the impact of not doing this? +(uncompleted) + +# Unresolved questions + +What parts of the design are still to be done? +(uncompleted) From 96105118fd93c83f83f5348bd337d2b9f3b8811b Mon Sep 17 00:00:00 2001 From: Benjamin Bollen Date: Mon, 5 Oct 2015 14:48:21 +0100 Subject: [PATCH 11/12] remove RFC from proposed --- ...pact-Unified-Structured-Data-on-Routing.md | 243 ------------------ 1 file changed, 243 deletions(-) delete mode 100644 proposed/0000-Impact-Unified-Structured-Data-on-Routing.md diff --git a/proposed/0000-Impact-Unified-Structured-Data-on-Routing.md b/proposed/0000-Impact-Unified-Structured-Data-on-Routing.md deleted file mode 100644 index 37d7148..0000000 --- a/proposed/0000-Impact-Unified-Structured-Data-on-Routing.md +++ /dev/null @@ -1,243 +0,0 @@ -- Feature Name: impact_unified_structured_data_on_routing -- Type: Enhancement -- Related components: routing and sentinel -- Start Date: 30-06-2015 -- RFC PR: (leave this empty) -- Issue number: (leave this empty) - -# Summary - -[RFC Unified Structured Data](https://github.com/dirvine/rfcs/blob/unified-structured-data/proposed/0000-Unified-structured-data.md) introduces `StructuredData` as a fundamental type for the network. -This RFC explores in more detail the implications for applying this change for routing -and sentinel library. - -# Motivation - -For the motivation on introducing `Unified Structured Data` we refer back to -the parent RFC. The motivation for the current RFC is to establish a collective -understanding of the changes needed for routing and sentinel to -implementing the parent RFC. This RFC explicitly excludes the intend to change -the design of the actual `StructuredData` and any such discussions should be -posted on the parent RFC. - -# Detailed design - -For the design of the actual `StructuredData` we again refer to the parent RFC. - -## Types -In routing three new fundamental types will be introduced `PlainData`, -`ImmutableData`, `StructuredData` - -### Plain data - -```rust -struct PlainData { - key : NameType, - value : Vec -} -``` - -Routing will not perform any additional validation on the PlainData type. -Default routing behaviour applies to this type, which is briefly recapitulated -below. - -### Immutable data - -``` rust -struct ImmutableData { - tag_type : u8, - value : Vec -} - -impl ImmutableData { - pub fn new(tag_type: u8, value : Vec) -> ImmutableData {} - - pub fn name(&self) -> NameType { - (tag_type + 1) Hash iterations of self.value - } - - // add lifetime if needed - pub fn content(&self) -> &[u8] { - &self.value[..] - } -} -``` - -Routing considers `ImmutableData` valid when a requested `name` equals -`immutable_data.name()`. - -### Structured data - -We repeat the structure as defined in the parent RFC - -``` rust -struct StructuredData { - tag_type : u64, - identifier : NameType, - data : Vec, - owner_keys : Vec, - version : u64, - previous_owner_keys : vec - signature : Vec -} - -impl StructuredData { - pub fn new( - tag_type : u64, - identifier : NameType, - data : Vec, - owner_keys : Vec, - version : u64, - previous_owner_keys : vec - signature : Vec) -> Result { - // validate: - // 0. total size <= 100 kB - // 1. must always be owned - // 2. on version == 0, no signatures needed - // 3. if previous owners set: check signatures with majority - // of their keys - // 4. if no previous owners: check signatures with majority - // of their keys - construct!() - } - - pub fn name(&self) -> NameType { - SHA512(tag_type + identifier) - } - - pub fn content(&self) -> &[u8] {} - - pub fn add_signature(&mut self, - private_sign_key : &crypto::sign::SecretKey, - public_sign_key: &crypto::sign::PublicKey) -> Result {} - - pub fn is_valid_successor(&self, successor: &StructuredData) -> bool { - // see detailed discussion of logic below - } -} -``` - -- `data` Routing does not parse the `data` field; it is always considered -as serialised bytes. -- `version` Routing does not (currently) attempt to resolve concurreny issues; -as such `version` is unused at routing. Additionally routing has no knowledge -of the previously stored valid version. The version number is for the user. -- `tag_type` Routing does not attach meaning to the 8 byte `tag_type` and treats -all tag_types equal. -- the signature should sign in bytes that are concatenated -in the following order: `data`, `version`, `owner_keys` and -`previous_owner_keys` - purely as a matter of convention. - -Corresponding `get` functions for all data fields are implied. - -#### logic for valid succession of structured data - -The structured data is recursively validated strictly on the preceding version. -That is the validity of a `StructuredData` of version `n` can only depend -on the validity of the same `StructuredData` of version `n-1`. Here "same" -means "have the same name". For `StructuredData` of version `n = 0` the -validity is `true` (and hence ClientManagers can charge an account to create -new valid `StructuredData_v0`). - -The version number must strictly increase by one. -All structured data must be owned; transfer of ownership is discussed below. -A majority is 50%, as outlined in the parent RFC - -**case : previous owner field is empty** - -An empty `previous_owner_keys` vector implies that the `owner_keys` -of version `n` must match the `owner_keys` of version `n-1`. -The `previous_owner_keys` of version `n-1` is ignored. -In this case no transfer of ownership is executed. The signatures must -be validatable with a majority of the keys of the current owners of version `n`. - -**case : previous owner field is not empty** - -A non-empty `previous_owner_keys` vector implies that there is an intent to -transfer ownership. In this case the `previous_owner_keys` of version `n` -must match the `owner_keys` of version `n-1`. The signatures must be -validatable with a majority of the keys of `previous_owner_keys` of version `n`. - -#### efficiency consideration when validating the signatures - -As outlined above, a signed vector of public keys defines a fixed order of -the public keys that will be checked to validate the signatures (see above -on previous owners or not). On construction of a `StructuredData` -the `Vec` will be ordered to the fixed order defined by the -relevant `Vec`. - -Any validation effort will then in sequence iterate over the signatures, and -in sequence check the keys, starting from the same index. This is an -easy algorithm for minimizing the search for matching signatures. A better -algorithm can be suggested. - -## Impact on routing message - -Currently `RoutingMessage` has the following declaration with -an obligatory signature from the `Header::Source::fromNode` -```rust -pub struct RoutingMessage { - pub message_type: MessageTypeTag, - pub message_header: message_header::MessageHeader, - pub serialised_body: Vec, - pub signature : types::Signature -} -``` - -As every client connects to the network over a relocated relay node, -we can keep this obligatory signature and have it signed by the relay node. -This puts responsibility on the relay node when injecting client messages in -the network, and keeps consistency that the from_node on the network is always -the id of a relocated node, not the hash of a 32byte client PublicKey. - -RoutingClient will sign RoutingMessages with the generic unrelocated Id -it self-generates on construction. This generic Id is unrelated to the keys -for signing ownership of structured data; it is purely and internally used -by routing to identify client-relay connections, per session. - -## Conservative approach to MessageTypes - -Routing can reduce to the following message types; the main motivation -is to simplify the message handlers. However, we will first go for -a conservative approach and extend the existing paradigm. - -This requires updating `GetData`, `GetDataResponse`, `PutData`, `PutDataResponse`. -It leads to introducing `Post`, `PostResponse`, `Delete`, `DeleteResponse`. - -The corresponding handlers need to be updated/written, replacing `serialised_bytes` -with `UnifiedData`. - -``` rust -pub enum UnifiedData { - PlainData, - ImmutableData(u8), - StructuredData(u64) -} -``` - -## also update with UnifiedData enumeration -This list is not exhaustive; all previously `serialised bytes` -need to be updated to a `UnifiedData`. - -- `NameTypeAndId` -- `MessageAction` -- `MethodCall` -- `RoutingMembrane::Put`, `RoutingMembrane::Get`, etc -- `RoutingClient::Put`, `RoutingClient::Get`, etc -- `NodeInterface` -- `ClientInterface` - -# Drawbacks - -Why should we *not* do this? -(uncompleted) - -# Alternatives - -What other designs have been considered? What is the impact of not doing this? -(uncompleted) - -# Unresolved questions - -What parts of the design are still to be done? -(uncompleted) From 00fff65416ef4ae9ec050dd5b2515591da7e33c4 Mon Sep 17 00:00:00 2001 From: Benjamin Bollen Date: Mon, 5 Oct 2015 15:41:32 +0100 Subject: [PATCH 12/12] remove RFC outline --- active/0000-Unified-structured-data.md | 7 ------- 1 file changed, 7 deletions(-) diff --git a/active/0000-Unified-structured-data.md b/active/0000-Unified-structured-data.md index 385b310..d8eea26 100644 --- a/active/0000-Unified-structured-data.md +++ b/active/0000-Unified-structured-data.md @@ -129,13 +129,6 @@ Status quo is an option and realistic. -------------------------------------------------------------------------------- # Addendum -- Feature Name: impact_unified_structured_data_on_routing -- Type: Enhancement -- Related components: routing and sentinel -- Start Date: 30-06-2015 -- RFC PR: (leave this empty) -- Issue number: (leave this empty) - # Summary [RFC Unified Structured Data](https://github.com/dirvine/rfcs/blob/unified-structured-data/proposed/0000-Unified-structured-data.md) introduces `StructuredData` as a fundamental type for the network.