Decentralized ANO Management

As indicated in my recent update, I built a prototype for decentralized ANO management, as described in my blog post on the subject. I'm happy to report the prototype is working, though it is not ideal for deployment yet.

The Network Control Panel (NCP) is a standalone app with a web interface, at the moment. The NCP only requires a node on the network to function, thus it is possible to have a public NCP connected to the open node, for example. My idea was to eventually integrate it to the factomd control panel.

Important
This update is technically a hardfork, as in followers that do not understand the message are unable to follow along with the block. However, the admin block message that results is unchanged, meaning that nodes can still process blocks. Effectively, that means if this is implemented right now, followers that do not update would pause during blocks where a promotion/demotion happens for approximately two blocks, after which they download the blocks from a neighbor and resume normal operation.

Since these messages are somewhat infrequent, it may be tenable to go ahead with this feature.



NCP: https://github.com/WhoSoup/factom-networkcontrol
It is possible to compile and run the NCP right now and use it with the mainnet or testnet, though the messages it crafts have no effect on the network when submitted. Everything else works as intended.

Factomd: https://github.com/WhoSoup/factomd/tree/whosoup-multisig_promotion (this is a fork of v6.7.0)

The way the process works in the prototype:

Step One: Creation
This is done by one person and defines the action of what's about to happen, ie a promotion of a new ANO.

1. Create a new message
2. Change the timestamp to be at some point in the future
3. Share the resulting "raw message" on the forum/discord

Step Two: Signing
This is done by > 50% of servers (currently >23), once per server identity

1. Import the raw message into the NCP
2. Sign it either manually or with kambani
3. Share the resulting raw message on the forum/discord

Step Three: Submitting
This is done by one person after enough signatures have been gathered

1. Wait for the time dictated by the timestamp +/- 1 hour
2. Import the raw message with enough signatures
3. Submit it to the network


This is designed to be used with the server identity's block signing key. That's the same key that's set in LocalServerPrivKey in the factomd.conf for authority nodes.

Manual Signatures: This is accomplished via sign with ed25519, where the key is the hex key from the config, and the message is the "Payload for Manual Signature" field from the NCP.

Kambani Signature: This is done with the Kambani extension in the chrome web store. @Valentin Ganev is in the process of adding support for the block signing keys directly, meaning you can just import the hex key from the config, but in this prototype that is not possible, so I used the hex key converted to a Factoid key.

If you want to run the prototype locally, I have provided four configs to use:


Instructions:
Code:
1. Compile the multisig branch to "factomd"
2. Compile the master branch to "factomd-old"
3. Place the config files into your "./factom/m2/" folder
4. Run the 4 servers
5. Type "g5" and hit enter in the console window of the first instance.
6. Run the NCP with "-f localhost:8088"

factomd -db=Map -customnet=multisig -blktime=60 -config=server0.conf
factomd -db=Map -customnet=multisig -blktime=60 -config=server1.conf
factomd -db=Map -customnet=multisig -blktime=60 -config=server2.conf
factomd-old -db=Map -customnet=multisig -blktime=60 -config=server3.conf
The four keys to import into Kambani are:
1. server0: Fs1tvKMM5FzkX5ri39FjKyt5cJpkK577doje28Pu9hVHVvbWgUaB
2. server1: Fs1kGN1uq1u34GbL7qkmCLrrKWrYqFwY1rjsoHoa1P5wpfcFUpJ3
3. server2: Fs1kGN1uq1uCiJ3Ywuc11s4WfqeMhyehNyiEe4k1VsPyEpq72KWs
4. server3: Fs1kGN1uq1u4FmhrhVGL4VHUZ9RAxh13EeCwku7UCEj1byyxSRmX

Some screenshots:
1596554461256.png1596554468038.png1596554472272.png


Todo:
  • The support for block signing keys in Kambani
  • Displaying an error when an identity is not correctly registered
  • Merging signatures from messages
  • A better UI

Wishlist:
  • A way to share in-progress messages across the network instead of forum/discord
  • Support for signing messages in Kambani instead of the workaround

The big question now is: Is this something the community wants further developed? There is still a chunk of work left in regards to testing and making the user experience smoother.
 
Thanks Who! Maybe I missed it but why step 2.3 is not done directly on chain? And step 3 looks very manual (so prone to human error). Is it in order to keep things simpler from an onchain consensus point of view?
Dev time, mostly. I wanted to implement the baseline of what needs to happen by implementing the multisig procedure on the factomd end so that we have a working feature that could be rolled out quickly if need arises.

An automated version on-chain could look like:
Setup: A new Chain X is defined
1. Someone makes a new request in the node-integrated NCP and it writes a signed entry to X
2. All the nodes see the new entry and display that request in the NCP
3. Operators can accept or reject that entry. By accepting, they write an entry confirming their intent
4. As soon as enough confirmations exist, the message is created using the timestamp of the block where the last confirmation was in
5. All nodes that signaled intent sign it and post that signature to X
6. As soon as enough signatures exist, every ANO broadcasts the message

The benefit here would be that ANOs already have the block signing key in memory, so the operator would never have to do anything beyond clicking a button. And the timestamp is only defined in step 4, giving us more flexibility like very short wait times if all ANOs are present without the risk of it failing and having to redo it.

The downside is that operators would also need to set up and maintain ECs for the node to keep the ledger consistent, or we code in another special chain like the fct/ec/admin chains that ANOs can write to freely. This is fairly minor and we could just have a communal EC address that someone funds with a couple EC before a vote. (Note: it may be possible for ANOs to just write data without payment, I haven't investigated that possibility.)

In any case, this is pretty doable but it was far outside the scope of this prototype.
 
we could just have a communal EC address that someone funds with a couple EC before a vote. (Note: it may be possible for ANOs to just write data without payment, I haven't investigated that possibility.)
Having a courtesy/communal address is not a problem, but as far as I understand the private key will be revealed into source code, if we built-in it into factomd? This may open an attack vector when someone is constantly emptying this address and ANOs are unable to vote.
 
We can do this as a soft fork pretty easily.

We add the code to factomd and external tools to use a voting system system across the ANOs to add and remove ANOs.

Then we make the signing keys used currently for messages to add and remove leaders public.

Code in the leaders verify leader adds and removes using the new method, ignoring signatures, and refuse to build on Admin blocks that contain invalid leadership changes (this is how the code works today).

Old nodes still validate all leadership changes, because the signatures work (of course they work, the private keys are public), but the public can't force leadership changes with that knowledge because they can't send properly validated ANO messages into factomd that are respected by the leaders (the only nodes that can add to the admin block).

There is a small risk of DDOS attacks among existing followers by sending invalid leadership change messages that appear to be signed properly, but updated nodes will simply ignore those messages. So assuming we get updates to all the ANOs, the backhaul servers, Open Node infrastructure, and we don't make the private keys truly public, but just distribute them to trusted parties, DDOS attacks are not too much a concern.
 
We can do this as a soft fork pretty easily.
Yes, this would work fine. Given this option, developing an on-chain system is preferable and I'll start working on that. How committed is Inc. on giving the keys to ANOs (it makes sense for all ANOs to have them but not the general public)? There have been requests in the past for Inc. to start sharing access that weren't granted.
 
Yes, this would work fine. Given this option, developing an on-chain system is preferable and I'll start working on that. How committed is Inc. on giving the keys to ANOs (it makes sense for all ANOs to have them but not the general public)? There have been requests in the past for Inc. to start sharing access that weren't granted.
I don't think Factom Inc. (and honestly every ANO) have had an issue with giving keys to ANOs, exactly. The problem is security, because even with all honest ANOs, distributing private keys is a good way to increase the risk of hacking.

If we change how the security around how ANOs are actually managed, then the current keys become (mostly) useless to a hacker since the real security is in the new system. So there is a vastly reduced security issue in distributing the keys to ANOs. We just risk DDOS attacks from a hacker until most of the nodes have been upgraded.
 
We just risk DDOS attacks from a hacker until most of the nodes have been upgraded.
I thought about this further and think it might not be an issue. AddServer/RemoveServer messages still require ACKs, so at most an attacker would be able to fill up a node's holding map (which they can already do with other messages), but without the ACK it would never make it into the PL.
 
I have picked this up again and revised the workings significantly for a better user experience. The idea is that each node in the authset has a control panel ("network control") that allows them to see currently active proposals and vote yes/no on them by clicking a button. Since the auth nodes already know their own block signing key, this means you won't have to manually sign messages. It does mean you'll need to secure the network control panel (it will be on a separate port than the regular control panel for this purpose).

The proposals and votes all happen on chain and the messages for the results are then automatically generated and added to the process list. Once the system is in place, Inc. can share the skeleton key with ANOs, who can add it to the config and allow the servers to send the messages to legacy clients who ask for them.

For more details, see: https://github.com/WhoSoup/factomd/blob/ano_management/modules/networkcontrol/README.md
 
Top