Blockchain/ Distributed Ledger

  • 1.  DLTSF-SUBGROUP Proposal for new Subgroups

    Posted Jul 01, 2020 11:19:00 AM
    Hello Everyone,

    Here are a few items currently missing from the list of sub-groups. Should we look at forming two additional sub-groups ? Open to feedback. Thanks. Urmila

    1. Blockchain Governance: This handles the software rules that codifies the architecture of a blockchain as decided by the business owner.
        
    It is responsible for:

    1) Inter-System Dependencies - Blockchains are not all self-sufficient. Thought needs to be given to the inter-system dependencies that a blockchain would rely on to operate.   This is in addition to the Third party ecosystem of DApps. For example Blockchains may need to  interface with other Blockchains/Proprietary databases to function.

    2) Codebase creation: Coding from scratch or leveraging existing frameworks

    3) Rules Agreement : that joint venture owners decide on how to operate the network ( example:  who is accountable for an incident ?)

    4) Protocol Governance: when/ how and if  to change a protocol to align with business needs 


    2. Networks: This is a critical component that handles the overall  Communication protocol to the entire P2P Network as well as the details of the Transaction Processing & its validation.



    ------------------------------
    Urmila Nagvekar
    President
    Smart Cyber Defense
    ------------------------------


  • 2.  RE: DLTSF-SUBGROUP Proposal for new Subgroups

    Posted Jul 01, 2020 12:00:00 PM
    Urmila :

    Thanks for the proposal of new sub-working group, I completely agree and added additional thoughts in bold below. 

    1) Inter-System Dependencies - Blockchains are not all self-sufficient. Thought needs to be given to the inter-system dependencies that a blockchain would rely on to operate.   This is in addition to the Third party ecosystem of DApps. For example Blockchains may need to  interface with other Blockchains/Proprietary databases to function.

    Main focus of this should be on data sharing and privacy, the traditional data sharing agreement may not work in the blockchain world due to the nature of the ledger (immutability, transparency). So, it will be important to business owners.


    2) Codebase creation: Coding from scratch or leveraging existing frameworks

    Most blockchain projects leverage existing open source code, the security and license requirements of the open source or third party code base certainly needs to be considered from risk management perspectives.

    3) Rules Agreement : that joint venture owners decide on how to operate the network ( example:  who is accountable for an incident ?)

    This would include areas such as security incident response, legal framework, risk management of blockchain network participants. It is very important for the business owners.

     
    4) Protocol Governance: when/ how and if  to change a protocol to align with business needs

    Open source project such as Compound and MakerDAO has some experiment work on leverage on-chain voting to change protocol to align business needs. The whole Protocol Governance is very important and we do need some smart minds to figure this out.

    Overall, in CSA GCR, there is no such group yet. So, the efforts of this sub-group will be very helpful.

    CSA GCR does have the network security working group headed by a University professor  and dean of computer science in one of the top University in China. Depends on the progress, I can coordinate some meetings for this.

    In addition, we do have DID Security working group, and I have shared the initial work in PPT in another discussion thread. 



    ------------------------------
    Ken Huang CEO
    ------------------------------



  • 3.  RE: DLTSF-SUBGROUP Proposal for new Subgroups

    Posted Jul 08, 2020 03:57:00 PM
    Here is the text from DOD analysis of blockchain which is relevant to this discussion:

    See: https://www.crowell.com/files/Potential-Uses-of-Blockchain-Technology-In-DoD.pdf


    Too many recent DLT experiments or proofs of concept have focused solely on the technology.
    They have been conceived and developed by a single entity emulating a value chain across
    simulated network participants. These are great technology learning experiences and should not
    be undervalued as such. However, the technology is the easiest part of implementing these new
    business processes or models. The harder part is getting true networks to come together and
    develop workable and agreeable operating and governance structures. A network participant
    must perceive value in participation and believe that the policies, intellectual property,
    governance structures and business values embodied protect their mission or business model.
    A network framework that provides the necessary operational and governance structure with the
    network or consortium at its core also needs to cover five additional key factors, which each
    have their own unique considerations:
    • Operations – designating day-to-day operations and maintenance responsibilities.
    • Business impacts – understanding impacts to core business processes.
    • Compliance – adapting to accommodate potentially varied rules and regulations.
    • Talent – sourcing the right people to lead implementation and sustain the operations.
    • Technology – navigating through rapid technological changes.

    ------------------------------
    Ken Huang , Chair, Blockchain Security Working Group, CSA GC
    ------------------------------



  • 4.  RE: DLTSF-SUBGROUP Proposal for new Subgroups

    Posted Jul 09, 2020 07:43:00 AM
    Speaking of the blockchain "network" I feel like we need to pin down exactly what that is (typically anyways), e.g. between Bitcoin, Ethereum and Ethereum 2.0 (with a Beacon chain "on top") defining what the network is exactly is becoming increasingly complex.

    I've started tagging key terms in the glossary (https://github.com/cloudsecurityalliance/Glossary/tree/master/glossary) with the tag "BlockchainArchitecture". The list isn't complete yet:

    • Beacon Chain
    • Blockchain Network
    • Block
    • Consensus
    • Consortium blockchains
    • Certificate Management
    • Chain
    • Fabric Tier
    • Indirect Participation
    • Intermediate Certificate Authority (CA)
    • Integration Tier
    • Key Management
    • Member Node
    • Public Blockchain
    • Private Blockchain
    • Secrets Management
    • Validator Node
    My goal is at some point to generate a generic list of blockchain architecture terms and interactions so that terms like "network" or "what does the exchange talk to" can be better defined (and technologies with different setups/exceptions can more easily note them). 

    If you can go through the Glossary and let me know which additional terms should be tagged with "BlockchainArchitecture" and post it here that'd be helpful, thanks!

    ------------------------------
    Kurt Seifried
    Chief Blockchain Officer and Director of Special Projects
    Cloud Security Alliance
    [email protected]
    ------------------------------



  • 5.  RE: DLTSF-SUBGROUP Proposal for new Subgroups

    Posted Sep 18, 2020 09:15:00 AM
    For Blockchain/DLT networks do we have a good model of what that means exactly? E.g. in the network world we have the 7layer OSI model, or in web we have the various layers/components of web apps. I'm thinking about this "network" and trying to pin down what it means exactly, especially in light of vastly different Blockchain/DLTs (e.g. Bitcoin vs Ethereum vs Ethereum 2.0 with a Beacon chain, etc.). 

    I've started tagging items in the glossary (https://github.com/cloudsecurityalliance/Glossary/tree/master/glossary) with "Tag: BlockchainArchitecture" in the file if that term pertains to a specific Blockchain/DLT component, so far there is:

    • Blockchain Network
    • Block
    • Consensus
    • Consortium blockchains
    • Certificate Management
    • Chain
    • Fabric Tier
    • Indirect Participation
    • Intermediate Certificate Authority (CA)
    • Integration Tier
    • Key Management
    • Member Node
    • Public Blockchain
    • Private Blockchain
    • Secrets Management
    • Validator Node
    there's obviously a lot more core terms to identify. Can you go through the glossary and let me know which are the other core terms you think we should tag with "BlockchainArchitecture" and I can (or you can do it and submit a pull request, either way works). Thanks

    ------------------------------
    Kurt Seifried
    Chief Blockchain Officer and Director of Special Projects
    Cloud Security Alliance
    [email protected]
    ------------------------------



  • 6.  RE: DLTSF-SUBGROUP Proposal for new Subgroups

    Posted Sep 21, 2020 08:27:00 AM
    Edited by Carlos Dominguez Sep 21, 2020 08:33:24 AM
      |   view attached
    Hi Kurt,
    "Blockchain/DLT networks" can have several meanings:
    - The physical network as ICT. Example: the aggregate of nodes exchanging messages via some protocols
    - The technical business network definition in the platform. Example: Hyperledger defines Business Network as per a set of model files, access files and access control file. Corda defines Business Network as an abstraction layer on top of Corda Network supported by membership services.
    - The business network as abstraction of the platform for the purposes of governance

    I think the definition will depend on which layer is under consideration, with "consensus" being another layer to consider. There have been several attempts at defining a model that includes all layers (see attached paper), but there does not seem to be a consensus as the academic work is lagging behind technology development.

    Personally I don't think the OSI model can express the structure of a blockchain network, but it can express the structure of a node.

    My personal definition is a fall back to Berkeley Blockchain Technology definitions where a "blockchain network" is type distributed system including a number of components and designed with a goal of  correctness of operation via consensus.
    Components:
    • Nodes: meant to represent separate machines, or processes.
    • Message passing: represented as arrows, or "edges" in the context of graph theory
    Correctness is defined as what must happen and what must not happen in the network (distributed system) in terms of Safety and Liveness properties:
    • Validity (Safety Property): any value decided upon by the network must be proposed by one of the processes (consensus result must not be arbitrary or hardcoded)
    • Agreement (Safety Property): all non-faulty processes must agree on the same value (don't bother with faulty processes, but with the remainder)
    • Termination (Liveness Property): all non-faulty nodes will eventually decide on some value

    Consensus is defined as a design answer to the CAP theorem for distributed systems, which is connected to the Safety and Liveness properties:
    • Consistency: defined as every node providing the most recent state of the system. If it does not have the most recent state, it will not provide any response (Safety as it refers to something that will never happen).
    • Availability: means that every node has constant read and write access. An available system allows to make updates and retrieve the state of the system without delay (Liveness as it refers to what must happen)
    • Partition Tolerance: A partition is an inability for two or more nodes in a network to communicate with each other. It includes unbounded network latency. Partition tolerance (Safety as it specifies what must not happen) states that the network will not stop functioning even with partitions.


    ------------------------------
    Carlos Dominguez CISSP, CISA, SABSA SCF
    ------------------------------