From 4c4053e08949e45d8d786f9bd8a7b37a74adf1f3 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Vitor=20Naz=C3=A1rio=20Coelho?= Date: Fri, 21 Dec 2018 21:17:15 -0200 Subject: [PATCH 1/4] Initial draft --- nep-X.mediawiki | 38 +++++++++++++++++++++----------------- 1 file changed, 21 insertions(+), 17 deletions(-) diff --git a/nep-X.mediawiki b/nep-X.mediawiki index 9e78b5dc..86c43410 100644 --- a/nep-X.mediawiki +++ b/nep-X.mediawiki @@ -1,40 +1,44 @@ 
   NEP: 
-  Title: 
-  Author: 
-  Type: 
+  Title: Proof-of-Safety
+  Author: Vitor N. Coelho, Igor M.Coelho, et al (join us!)
+  Type: Standard
   Status: Draft
-  Created: 
-  Requires (*optional): 
-  Replaces (*optional): 
+  Created: 2018-12-21
==Abstract== -A short (~200 words) description of the technical issue being addressed. +Massive decentralization has the cost of safety. +It is impossible to deny that in unlucky cases `M` (safety level) nodes can be Byzantine and attack the Blockchain. +While there are different types of possible attacks, some of them are easy to detect, such as: 1- blocks with wrong transactions; and 2- blocks with double-spending. +Considering this possibility, this NEP proposes a simple deep-reorganization mechanism in which consensus nodes that signed the Byzantine Block are banned. +For ensuring safety by economic means, all consensus nodes will stake NEO (similar to what is done today) are may lose them in case of being Byzantine. -==Motivation== -The motivation is critical for NEPs that want to change the NEO protocol. It should clearly explain why the existing protocol specification is inadequate to address the problem that the NEP solves. NEP submissions without sufficient motivation may be rejected outright. +==Motivation and Rationale== -==Specification== +After https://github.com/neo-project/neo/pull/426 is merged it is believed that no more natural forks will occur on the network. +Then, some additional safety mechanism should be implemented in order to boost massive decentralization. -The technical specification should describe the syntax and semantics of any new feature. The specification should be detailed enough to allow competing, interoperable implementations for any of the current NEO platforms. +==Specification== -==Rationale== +A new message should be added, in which nodes can report the byzantine blocks. +Initially, there will be two types of possible bans: -The rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work, e.g. how the feature is supported in other languages. +* If the block contains wrong transactions all nodes that signed that blocked are automatically banned, removed as validators and losing their stake; +* If two/more blocks on a same height are reported, the longer branch (with, at least, more than `X` blocks. `X` should be defined in a safety manner. Maybe 2 blocks could be enough) will be defined as the correct chain and all signatures from the other branches will be banned. -The rationale may also provide evidence of consensus within the community, and should discuss important objections or concerns raised during discussion. +In both cases the Blockchain will be deep reorganized and re-synced. ==Backwards Compatibility== -All NEPs that introduce backwards incompatibilities must include a section describing these incompatibilities and their severity. The NEP must explain how the author proposes to deal with these incompatibilities. NEP submissions without a sufficient backwards compatibility treatise may be rejected outright. +This NEP requires a height definition where it will start, otherwise an attack can be done used any previous fault of the network. ==Test Cases== -Test cases for an implementation are mandatory for NEPs that are affecting consensus changes. Other NEPs can choose to include links to test cases if applicable. +TODO ==Implementation== -The implementations must be completed before any NEP is given status "Final", but it need not be completed before the NEP is accepted. It is better to finish the specification and rationale first and reach consensus on it before writing code. +TODO From 170247852004afceef00d5f13bf0007c36fa86c5 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Vitor=20Naz=C3=A1rio=20Coelho?= Date: Wed, 6 Mar 2019 21:43:22 -0300 Subject: [PATCH 2/4] Brief update on description (still need to adjust) --- nep-X.mediawiki | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/nep-X.mediawiki b/nep-X.mediawiki index 86c43410..8476e173 100644 --- a/nep-X.mediawiki +++ b/nep-X.mediawiki @@ -1,7 +1,7 @@ 
   NEP: 
-  Title: Proof-of-Safety
-  Author: Vitor N. Coelho, Igor M.Coelho, et al (join us!)
+  Title: Lightning-Voting
+  Author: Vitor N. Coelho, Igor M.Coelho, Jeff Solinsky, et al. (join us!)
   Type: Standard
   Status: Draft
   Created: 2018-12-21
@@ -12,8 +12,7 @@
 Massive decentralization has the cost of safety.
 It is impossible to deny that in unlucky cases `M` (safety level) nodes can be Byzantine and attack the Blockchain.
 While there are different types of possible attacks, some of them are easy to detect, such as: 1- blocks with wrong transactions; and 2- blocks with double-spending.
-Considering this possibility, this NEP proposes a simple deep-reorganization mechanism in which consensus nodes that signed the Byzantine Block are banned.
-For ensuring safety by economic means, all consensus nodes will stake NEO (similar to what is done today) are may lose them in case of being Byzantine.
+Considering this possibility, this NEP proposes a simple mechanism that allows voting to happen in an upper layer, namely, in the mempool.
 
 
 ==Motivation and Rationale==

From 9c78201e69d3cf34c5fefb0ec60ad38d0dcd144d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Vitor=20Naz=C3=A1rio=20Coelho?= 
Date: Wed, 6 Mar 2019 21:59:46 -0300
Subject: [PATCH 3/4] Updating description

---
 nep-X.mediawiki | 12 ++++++++++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/nep-X.mediawiki b/nep-X.mediawiki
index 8476e173..e6fcf08e 100644
--- a/nep-X.mediawiki
+++ b/nep-X.mediawiki
@@ -17,11 +17,17 @@ Considering this possibility, this NEP proposes a simple mechanism that allows v
 
 ==Motivation and Rationale==
 
-After https://github.com/neo-project/neo/pull/426 is merged it is believed that no more natural forks will occur on the network.
+After dBFT 2.0 was merged it is believed that no more natural forks will occur on the network.
 Then, some additional safety mechanism should be implemented in order to boost massive decentralization.
+Furthermore, in case that NEO holders detects missbehavior of CN they should be able to vote at any time.
+
+In addition, in a "normal" scenario where `f+1` nodes lose acess to their private key the network could stuck.
+In this sense, a mechanism should be prepared for the most adverse situation.
 
 ==Specification==
 
+TO CHANGE after the idea of lightining voting.
+
 A new message should be added, in which nodes can report the byzantine blocks.
 Initially, there will be two types of possible bans:
 
@@ -32,7 +38,9 @@ In both cases the Blockchain will be deep reorganized and re-synced.
 
 ==Backwards Compatibility==
 
-This NEP requires a height definition where it will start, otherwise an attack can be done used any previous fault of the network.
+This NEP will be fully compatible.
+
+However, it should be noticed that at any time of the history if votes are enough we could redesign the chain.
 
 ==Test Cases==
 

From b8beb2dafc87900b55fa90f9d3c5654a62d4d0ef Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Vitor=20Naz=C3=A1rio=20Coelho?= 
Date: Wed, 10 Apr 2019 13:25:45 -0300
Subject: [PATCH 4/4] Updating NEP description

---
 nep-X.mediawiki | 24 +++++++++++++++---------
 1 file changed, 15 insertions(+), 9 deletions(-)

diff --git a/nep-X.mediawiki b/nep-X.mediawiki
index e6fcf08e..eb8b6cc5 100644
--- a/nep-X.mediawiki
+++ b/nep-X.mediawiki
@@ -9,20 +9,28 @@
 
 ==Abstract==
 
-Massive decentralization has the cost of safety.
-It is impossible to deny that in unlucky cases `M` (safety level) nodes can be Byzantine and attack the Blockchain.
-While there are different types of possible attacks, some of them are easy to detect, such as: 1- blocks with wrong transactions; and 2- blocks with double-spending.
-Considering this possibility, this NEP proposes a simple mechanism that allows voting to happen in an upper layer, namely, in the mempool.
+Fully distributed systems have the cost of safety.
+
+It is impossible to deny that, in unlucky cases, M (safety level) nodes can be Byzantine and attack the Blockchain.
+While there are different types of possible attacks, some of them are easy to detect, such as: 1- blocks with wrong transactions; 2- blocks with double-spending; 3 - more than f consensus node lagging plenty of time to sign next block: among others.
+
+Considering this possibility, this NEP proposes a lightning voting experience, in which NEO holders would be able to modify validators during block creation.
+In this sense, this proposal is a simple mechanism that allows voting to happen in an upper layer, namely, in the mempool.
 
 
 ==Motivation and Rationale==
 
 After dBFT 2.0 was merged it is believed that no more natural forks will occur on the network.
-Then, some additional safety mechanism should be implemented in order to boost massive decentralization.
-Furthermore, in case that NEO holders detects missbehavior of CN they should be able to vote at any time.
+Then, an additional safety mechanism should be implemented in order to boost massive decentralization.
+Furthermore, in case that NEO holders detects missbehavior of CN they should be able to vote at any time, without having to trust that most of us will post your request
+
+The name Lightining Voting came with the idea that the voting is an offchain process. 
+The state channel with NEO blockchain was already created by means of UTXO or a Native Contract Asset.
+In this sense, as soon as NEO holders sign txs and the majority agrees with validators change, that could happen during block creation (and not only after publishing the vote intentation).
+
 
 In addition, in a "normal" scenario where `f+1` nodes lose acess to their private key the network could stuck.
-In this sense, a mechanism should be prepared for the most adverse situation.
+In this sense, this proposal is a mechanism that prepares NEO blockchain for the most adverse situation.
 
 ==Specification==
 
@@ -40,8 +48,6 @@ In both cases the Blockchain will be deep reorganized and re-synced.
 
 This NEP will be fully compatible.
 
-However, it should be noticed that at any time of the history if votes are enough we could redesign the chain.
-
 ==Test Cases==
 
 TODO