search

internet-sicherheit / eco-blockchain-governance

Working repo for the eco Blockchain Governance Framework
Apache License 2.0
5 stars 3 forks source link

Specify TODOs for working groups #7

Open beeshot opened 4 years ago

beeshot commented 4 years ago

Just looked at the structure Kevin suggested. If we assign the working groups to different topics of the table of content, it can be a good start. I was thinking if two working groups (governance and technology stack) could be an easier start. These groups could split into smaller groups according to layers and different areas such as legal, incentives& economics. Interconnection and synergies between topics may be realized sooner this way.

kiview commented 4 years ago

We can assign them to each working group on this issue discussion and then create an RFC (let's just say we use RFCs for now) PR for each one fo them.

I don't think we should introduce another hierarchical index (governance and technology stack) in addition to the 4 sub-groups since I don't think we should tackle technology topics here besides the technical (which handles topics such as technical monitoring) working group.

With regards to layers, we should focus on ToIP Layer 1, which can be considered the blockchain network and infrastructure layer.

beeshot commented 4 years ago

It would actually more erase a layer and is inspired by Trust over IP structure. to me it doesn't make sense to separate some of the topics and make an extra group for it, because it separates topics which may have to be thought in a holistic context.

kiview commented 4 years ago

It would actually more erase a layer and is inspired by Trust over IP structure

Can you please clarify what you mean by this? ToIP is a big framework, we will just tackle the bottom left box of it (which is governance of layer 1).

Can you give examples of topics you feel uncomfortable in separating? Just by assigning the work to dedicated workgroups does not mean that they can't be considered in their respective extended context.

beeshot commented 4 years ago

Clarifying legal and network governance already helped. Some of the questions may refer to more than one working group. e.g. legal, governance, and economic topics are connected, such as questions of (legal) accountability of members. Maybe it becomes more clear looking at the toc i wrote. Also had the impression there that some topics are difficult to disconnect from each other. As long as we refer to the working groups to a common table of content, it may not matter much

kiview commented 4 years ago

In accordance with yesterdays discussion, we should fix this issue by creating a list of TODOs, aka planned RFCs. The ToC by @beeshot and the Google Sheet document (link TBD) by @fflush serve as a base input.

kiview commented 4 years ago

Will take care of this now. Will post the result in this issue and then engage in communications with eco about how to distribute the tasks.

beeshot commented 4 years ago

RFC

Governance

[ ] What is the overall goal and motivation of the network? [ ] How to split decision rights? [ ] Which process is used to vote for new members? [ ] Which process is used to ensure and enforce compliance? [ ] How can governance model be changed? [ ] What are sanctions and events that trigger for sanction voting? [ ] How and why can a member be excluded? [ ] When and how can the blockchain be forked [ ] Who is egible to become a member? [ ] Which application process has to be followed? [ ] What is evaluation citeria for the application? [ ] How is voted for a new member? [ ] How will the note of a new member be activated

Legal

[ ] How is accountable and how can it be enforced? [ ] Which agreements need to be signed? [ ] Data Protection by Design and Default

Incentives and Economics

[ ] Is there a sustaianability principle that should be applied? [ ] Which currency will be used and what it's purpose? [ ] Are there fees? [ ] How to ensure regultory compliance?

Technical

[ ] Is a transaction author agreement needed? [ ] Is a transaction endorser agreement nedded? [ ] What kind of nodes can be run in the network? [ ] Permissioned Write Access? [ ] Public Write Access? [ ] Public Read Access? [ ] What consensus algorithm is used? [ ] Where are consensus algorithm and governance model are deployed? (e.g. Genesis Block & Smart Contracts?) [ ] What currency is used? [ ] What are Hardware Requirements? [ ] What are Software Requirements [ ] Security by Design [ ] Security Guidelines/Requirements [ ] How are updates handled [ ] How are new nodes validated [ ] Is there an alert system in place [ ] Monitoring of Hardware [ ] Monitoring of Network behavior [ ] How will the node be operated

Further Documents

Glossary Monitoring Back up Usage of Forensic Node

kiview commented 4 years ago

Thanks, will review and update ASAP.

beeshot commented 4 years ago

I wanted to upload it yesterday but did something wrong in Github, Asked @chinmay241 for help but couldn't fix it last night

kiview commented 4 years ago

Removed the points for which we already have an RFC and tried to generify to the same abstraction level (e.g. transaction author and endorser are Sovrin/ToIP specific concepts).

If there are obvious points anyone wants to grab, feel free to mention this here. Will communicate this list to eco and if it sounds like a good target, we can close this issue (since the TODOs are then specified) and creating an overarching TODO issue.

Governance

Legal

Incentives and Economics

Technical

fflush commented 4 years ago

With the technical TODOs, the difference in safety is missing. Once for specific nodes and once for general security. I would also like to see a general node policy. Finally, perhaps regulations for test environments. Apart from that I think the list is very good. There are some topics I don't know very much about, so I think we' ll find out later if there is any need for readjustment.

kiview commented 4 years ago

So you mean "Node operational security" and "Network security"? Does network security distinguish itself from network monitoring? Or is it network security monitoring?

What do you mean with general node policy?

Test and staging environments is an excellent point, Sovrin runs at least 3 environments, testnet, buildernet and mainnet.

fflush commented 4 years ago

I had oriented myself to the Sovrin Framework. That's where the idea of security comes from. Sovrin has node security policies and general security policies. The Operational Security Guidelines could have both, but I think this is getting to be too much. So I would put one on the node and a general one that includes personnel and physical security. I think we can cover network security by monitoring. That shouldn't be too much.

In the general node policy I would add the points that I don't see covered in the list. But maybe we can add one or the other. But that is to be discussed. I would understand the following points:

How can the alarm be implemented redundantly in the event of faults? Regulation of downtime? Network-wide planning of downtime? Updating the node configuration? Number of employees required to operate the node? Accessibility of the administrators? Time window for recovery after error or system failure?

kiview commented 4 years ago

How can the alarm be implemented redundantly in the event of faults?

Monitoring

Regulation of downtime?

Is this related to update policies?

Network-wide planning of downtime?

Maybe we need a point, node maintenance and network maintenance?

Updating the node configuration?

Isn't it effectively a node software update to a certain degree?

Number of employees required to operate the node?

I don't think Sovrin specifies this.

Accessibility of the administrators?

SLA and response times

Time window for recovery after error or system failure?

This is part of backup and restore I think. We could have an additional point, disaster recovery. Such a chapter is standard in software operation manuals in the enterprise context.

fflush commented 4 years ago

Okay, most of it would work for me. Regulation of downtime? and network-wide planning of downtime? is about hardware replacement and coordinating the other nodes to take over and not to fail too many at once. I like the point of disaster recovery.

Sovrin regulates the employees as follows: MUST have at least two (2) IT-qualified persons assigned to administer the node, and at least one other person that has adequate access and training to administer the Node in an emergency, such as the network being unable to reach consensus or being under attack. See the Sovrin Crisis Management Plan for details.

I'm not so easy on maintenance either. But I think it makes sense.

But the other one should fit.

beeshot commented 4 years ago

What about a RFC about the selection of a Board of Trustee and its role?

Maybe we should add: How to change criteria for members, as well? Or would it be the same as changing other parts of the framework?

kiview commented 4 years ago

What about a RFC about the selection of a Board of Trustee and its role?

Board of Trustees is a Sovrin concept. I don't think this will be directly reflected in our meta-framework.

How to change criteria for members, as well? Or would it be the same as changing other parts of the framework?

IMO this falls under Governance model change process. In case we see that this RFC would become too big, it could be split. But e.g. in bloxberg, changing membership criteria would happen by changing the governance model.

Of course, this list is not all-encompassing and new points will arise in the future, but as a starting point, we should not overextend our capacities as long as the number of contributors is limited.