DISCLAIMER: (Google Doc LINK) Please READ First (http://bit.ly/2Qw2Izy)
The other day in the Core Telegram Channel an idea came up that I initially thought, “yeah - we ought to do that”. That idea centered around the notion that when a validator uses the POA DApp for Proof-of-Physical-Address (https://popa.poa.network/register/) then perhaps the validator’s metadata (https://validators.poa.network/) should then be automatically updated. Basically:
POPA → Metadata
Again, at the time, I was all for this. But it was late at night and I think that everyone was/is keen on removing points of friction. As I can only speak for myself, I’ll refer to only myself from now on.
I am now suggesting that the better route would be:
Metadata → POPA
And as we know from studying if/then statements in school - direction matters.
Backing up a bit. I love to optimize systems. I’ve been known to spend weeks of effort to effectively shave off a few clock cycles - basically, I’m an idiot (I’ve been fortunate never to have been employed in CIS so I am afforded this insanity.) So when the initial idea was presented, I loved the idea of saving ‘time’ at all cost. Then I woke up the next day and while brushing my teeth realized an error of logic.
Firstly, what exactly are we trying to do and, more importantly, why? Validators are staking their identity and one component of this is an address. NOTE: the term “address” is complex and beyond the scope of this posting, so we will use a working definition: You can get a postcard.
When a validator presents an ‘address’, there is no “trust but verify” - rather there is “verify”. One of the duties of the validating set is to ensure all of other validators have provided an address that is ‘correct’ (again the exact nature around type of address is beyond the scope of this post).
So the goal under consideration for this post is the staking of an address.
The value of POA Network (again I’m only speaking for myself) is not as a cryptocurrency but rather as an Enterprise ready DApp platform. Basically, the network’s true value is in making stuff (other DApps) work. Why would someone select us over others? Because we offer a link connecting two worlds together: blockchain and traditional legal frameworks. Companies understand the latter and would like to explore the former. So being able to explain to the various levels of a corporation that actual human beings are tied to the running of a “blockchain based platform” gives them the assurance and comfort in taking those beginning initial baby steps. This is how this technology wins, slow and steady. (Again all of this is my own views - and no one else’s potentially). So we need to communicate to all that actual humans are doing this work, and human exist somewhere - with this ‘somewhere’ typically referred to as an ‘address’.
But isn’t POPA enough?
Well, no. Firstly, what does this DApp do? It creates a link between a key and an address. The idea being that it is trying to establish a control relationship between these two ‘things’. I.e. someone claiming to be “Jeff” controls this key which is linked to physical control of a mail receptacle in which to receive a postcard.
I will be assuming that the third party service/API that actually generates the postcard is ‘secure’. I’m also assuming that the mail delivery chain is also ‘secure’. Again, in any scientific inquiry there will be assumptions - you may or may not agree with these. I do believe that this could be itself another post. But for the purposes of this post, let us make this working assumptions.
Did we prove that Jeff lives at (and staked) an address?
Ans: No. (Hence the quotes around Jeff)
We have only demonstrated that a cryptographic key is associated with someone at said address.
This is significant in its own right, but this is not the original goal. I.e.: Jeff staking an address. We need to get “Jeff” into this equation.
This is where governmental attestation and the critical thinking/work of the entire validator network comes into play. Ideally for me (Jeff) to show that I have some address, I demonstrated more than simple physical access to a mail receptacle.
POA Network seeks to solve this issue through the requirement that all validators are Public Notaries. To become a Public Notary, ideally you will have had to show proof to a governmental agency of sorts. This attestation mechanism is the way that trust is built up. If you ‘trust’ that a governmental agency created a procedure on becoming a Public Notary and ‘trust’ that this process was followed by all parties, then said individual can be afforded this level of ‘trust’. Recall the transitive property from algebra.
A = B and B = C, then A = C
Trust Chain: Govt = Notary Process and Notary Process = Individual, then Gov’t = Individual
(Where we are tracking an acceptable level of trust.) I am grossly over simplifying … but I think we can understand.
So governmental attestation is a necessary condition. Is that enough? No. We now have the whole problem behind oracles - or rather: how to get information from the real world into a blockchain.
This is where the other validators come in. If you believe that the majority of the validators, beginning with the first three were/are legit then we can leverage them in a sort of law of large numbers manner. I’m going to be adding this too my list of working assumptions…
This now trusted set of validators can take in information from a trusted source (that whole gov’t attestation) and ensure that this has been information has been correctly entered into the blockchain. The entering of the data into the blockchain is exactly what the metadata DApp is for. Then it requires two validators (at the time of this posting) to verify this information by polling a governmental source (such as a governmental website listing all known notaries, their commision number, and address of record.)
So we have demonstrated the following set: (Jeff, Address)
This being the meat and potatoes that a corporate user would like to be assured of. These organizations typically understand how to send a subpoena should they feel strongly enough about a potential issue.
But what about that “key”? Though this is important, the POPA DApp isn’t setup at present to require any verification from the other validators. And again, it is this outside verification - using the other validators as oracles.
Put another way, we can think of POPA as the cherry on top. This DApp provides us with the following set: (Key, Address)
Using a generous helping of working assumptions we are finally in a position to perform the following:
(Jeff, Address) & (Key, Address) -> (Jeff, Key, Address)
We now have an association that spans the person, an address, and a voting key.
Since there is no verification for POPA outside of the physical control of a mail receptacle, the heavy lifting is performed by the metadata DApp. Therefore, I do think we could maybe have it that once a person has correctly used the validator DApp and all the information has been checked out by other validators using outside sources, then perhaps the whole postcard thing of the POPA is automatically run.
Of course this would require significant work to implement, as these DApps are not presently set up like this.
An idea to save time was to automatically update a validator’s metadata once they ran the POPA DApp; however, this is not correct. Perhaps though once the validator metadata DApp has been run, then the POPA DApp could be automatically called upon. This would require work to be performed on these DApps.