Internet of Everything

Expand all | Collapse all

Standardizing Blockchain

  • 1.  Standardizing Blockchain

    Posted Feb 07, 2018 18:52
    How can Blockchain as a technology be standardized as a security mechanism to be used across Telecommunications/Wireless carriers especially for IoT applications and on IoT endpoint devices?

    ------------------------------
    Mimi Tam
    Verizon Communications
    ------------------------------


  • 2.  RE: Standardizing Blockchain

    TM Forum Member
    Posted Feb 08, 2018 07:07
    Hi Mimi,

    It depends on the security mechanism you're trying to implement.
    A simple use is for software updates.
    You can put whatever you want into a ledger based blockchain, let's assume you're using JSON.
    New updates are published in the blockchain, with integrity and authenticity verification information, linking to a file.

    The real challenge with IoT and blockchain technology is the 'potential' size of the blockchain itself.
    The bitcoin blockchain is now over 20GB.

    A hypothetical IoT coffee maker may have a couple MB of storage.
    IoT manufactures will not put GB's of storage in small simple devices.




    ------------------------------
    Brian LaVallee
    INVITE Communications Co. Ltd
    ------------------------------



  • 3.  RE: Standardizing Blockchain

    Posted Feb 09, 2018 03:53
    ​I think the three limitations for Blockchain for IOT currently is Mining, Block Size and Latency.....however with the investment being made in the technology I am sure we will see more IOT use cases around blockchain

    I would never have thought of blockchain in the below scenario:

    https://www.sdxcentral.com/articles/featured/opencts-bd-wan-platform-aims-transform-telcos/2018/02/

    Here is a use case from IBM however the technicalities are not very clear

    IoT Application Using Watson IoT & IBM Blockchain
    Mendix remove preview
    IoT Application Using Watson IoT & IBM Blockchain
    The Internet of Things (IoT) has opened up countless opportunities for businesses to drive smarter operations. Virtually every device and asset around us is becoming equipped with sensors that transmit data to the cloud. Naturally, many companies are eager to make IoT applications part of their business to drive new experiences, cut costs and generate efficiency.
    View this on Mendix >



    ------------------------------
    Ravendran Naicker
    Liquid Telecom South Africa
    ------------------------------



  • 4.  RE: Standardizing Blockchain

    TM Forum Member
    Posted Feb 12, 2018 03:49
    Edited by Brian LaVallee Feb 12, 2018 03:51
    Hi Ravendran,

    Mining and Block Size are both limitations that affect crypto based currencies, especially evident with bitcoin.

    "Cryptographic Mining" is not required for blockchain technology, but you do require some work to perform to trigger folding the next block into the chain.  But this could simply be time-based of some other simple proof of work.  It does not require custom rigs with GPU's.

    A simple blockchain example:
    https://hackernoon.com/learn-blockchains-by-building-one-117428612f46

    Block size is a major contention point among bitcoin developers.  Again, this is a problem with crypto based currencies.  The popularity and scale of bitcoin was simply underestimated.   That does not mean it can not be changed, but it's just difficult to fix without the bitcoin developers reaching a consensus.  Any blockchain adopted for IoT use may reach the same block size headache, it's hard to predict 5~10 years into the future with any accuracy.

    When it comes to latency, blockchain technology will always be slower than direct methods of communication.  The SDxCentral article was very careful to say, "near-zero time delay".  Which could subjectively mean hours are nearer to zero than days.

    The sweet-spot for blockchain IoT is probably Command, Control & Intelligence (C2I).  Blockchain will not be for turning ON the lights in my home right now, but will be great for setting or updating a daily lighting schedule.  The SDxCentral article showed the blockchain being used for C2I, pushing changes to modify a WAN network environment, providing capacity changes to reflect updated requirements.

    With C2I, there is also the aggregation of data.  Where any data point could be fed into a blockchain for external evaluation.  The IBM article shows the blockchain simply being used as a temper-proof ledger, data populated by IoT devices, and parsed for abnormalities with the Watson engine.  The analog method, would be following a paper trail back to the source to find where something went wrong.

    ------------------------------
    Brian LaVallee
    INVITE Communications Co. Ltd
    ------------------------------



  • 5.  RE: Standardizing Blockchain

    TM Forum Member
    Posted Feb 13, 2018 01:59
    @Brian LaVallee has nailed it. What we need to explore is the right use case and the "method of deployment" of any distributed ledger for IoT. We've started looking at a few scenarios, but already there are a couple of fancy implementations in the public space also of Access-Authorization-Accounting (AAA) with IoT that do not use the consensus models that cryptos use. The use case requires the appropriate consensus and voting mechanism for recording to the ledger. AAA use cases are hot because of the fear of what happens in 2016/2017 with DDoS attack on IoT's that brought some DNS sites down.

    ------------------------------
    Emmanuel A. Otchere
    VP, Industry Development & Standards
    Huawei Technologies Co. Ltd
    ------------------------------



  • 6.  RE: Standardizing Blockchain

    Posted Feb 14, 2018 02:31
    ​Hi Brian,

    I do agree on scoping Blockchain for specific use cases however the tech needs to be understood in the context of the business problem you are trying to solve, for example I worked on something using IOT and Blockchain for a specific scenario based on a customer wanting some automation which after careful investigation of all tech Blockchain was the only tech that could achieve what we wanted.  However the tech did give us some challenges for example scale and device power, but with the right partner and skills we did solve the issue.

    What I have seen from the industry is around Blockchain hype and creating a fear of missing out, this is not what Blockchain is meant to be about, similar to AI around deep learning. A clear understanding of Tech is required while also looking at tried and tested methods out there other than Blockchain in trying to solve the business problem you have at hand.

    Thanks
    Raven

    ------------------------------
    Ravendran Naicker
    Liquid Telecom South Africa
    ------------------------------



  • 7.  RE: Standardizing Blockchain

    TM Forum Member
    Posted Feb 15, 2018 08:22
    Edited by Thandi Demanet Feb 19, 2018 13:14
    Hi all,

    Great discussion going on here. I just wanted to make you aware of this TM Forum technical report created through our collaboration programme and available to members. The paper gathers and addresses use case for blockchain or distributed ledger technologies from a CSP and IoE perspective including smart contracts, identity management, managing micropayment... https://www.tmforum.org/resources/technical-report/tr279-csp-use-cases-utilizing-blockchain-r17-5-0/

    Remember to join the IoE & Digital Ecosystems programme if you've not yet done so, it's easy to sign up here: Log In - TM Forum Confluence

    Any feedback or input into this is always welcome. Feel free to get in touch with us via the comments box under this document or via e-mail: thandi.demanet@tmforum.org

    ------------------------------
    Thandi Demanet
    Business Analyst - IoE & Digital Ecosystems Program
    TM Forum
    ------------------------------



  • 8.  RE: Standardizing Blockchain

    TM Forum Member
    Posted Feb 26, 2018 14:25
    Mail Reply from Siddharth Mohapatra:

    With these many constraints in Blockchain especially with respect to the delay in transmission of data, I was just wondering, shouldn't the Blockchain technology be merely used for reporting purpose rather than using it for day to day activities in IoT because every information that is transmitted from one block to another is just going to remain in that block forever(if my understanding on blockchain is correct, absolute deletion of data is not possible), so the line items would pile up in the block and remain there and whenever we need to search for any information(even though we know the block address), subsequently it would take more time to search for the data in a given block that it takes now. So basically the latency is going to increase as we go further and we are back to the primitive age then. Isn't it? Your view point please?


    Hi Siddharth,

    You're right, blockchain technology is extremely useful for reporting purposes. Especially data-sets that needs to be protected against bad actors. Where immutability and it's distributed nature prevents tampering. There are many potential uses.

    Blockchain technology should be considered a form of WORM (Write Once, Read Many) data storage. (Your understanding on blockchain is correct!) Once the data is written to a block, it can not be modified or deleted. Every block in the blockchain is required to verify the integrity of the next block in the chain.

    Deciding what data goes into a blockchain should follow some of the same use considerations as WORM data storage. But blockchain technology does not have the same capacity limitations as physical WORM storage, a blockchain could theoretically reach petabyte, exabyte, zettabyte, or even yottabyte scale. Eventually causing the miners to halt or make the data difficult to access from commodity hardware.

    A few thought experiments to push the boundaries of blockchain technology are: call detail records, syslog, and MRTG data. There are some valid reasons to insure the integrity of these datasets, but they all have the potential to grow very large. With blockchain technology you can't prune the CDR, rotate log files, or RRD graph data.

    Before addressing IoT/IoE devices using data in the blockchain, I would say that my point of view is strictly from inside-the-box. The blockchain, clients, miners, and the peer-to-peer network. Don't care about tokens to spend or the data in a block, since anything could be in a block.

    I avoid hybrid outside-the-box solutions, since thy have the potential to break or circumvent the integrity and security of blockchain technology. Basic blockchain technologies have enough issues, the potential size of the blockchain is a primary concern, and let's not forget the "51% attack" vector.

    Using a blockchain to communication with an IoT/IoE device is possible, but there will always be latency. It's indirect, a message is passed to the miners to be included in the next block. Once the new block is generated, it will be distributed via peer-to-peer to participating clients. The IoT/IoE device checks the new block for messages that are addressed to the device or hardware model.

    The sweet-spot here would be Command and Control situations, pushing firmware updates, patches, updated ACL's, CRL's, or some other data used by a device. Similar to the methods and techniques used to control bot-nets, which also employ security mechanisms.

    Avoiding analytical applications that use the blockchain, clients search blocks in sequential order. Downloading the genesis block, verifying the integrity, checking for messages, and downloading the next block in the chain. Download, verify, check for messages, repeated over and over and over.

    Only the last few blocks are necessary for verifying blockchain integrity. Earlier blocks could be stored locally or discarded. I often point out the potential of running out of local storage capacity. Discarding earlier blocks has its own drawbacks, rebooting a device could take hours or days to download the blockchain from genesis to the most recent block.

    A larger blockchain will not affect latency. But without storing the blocks locally, a reboot will take longer and longer for a device to reach a ready state. And this ready state becomes important when relying on the blockchain to secure an IoT/IoE device. Making the device inaccessible until the blockchain is processed up to the current block.

    Messages that are addressed to a device, containing security information or a command to execute, could be handled in a couple or ways. Messages could be processed immediately or kept in memory until all the blocks have been checked, processing just last received. There could be tens-of-thousands of blocks in a blockchain, but only a handful may contain messages for a specific device.

    ------------------------------
    Brian LaVallee
    INVITE Communications Co. Ltd
    ------------------------------



  • 9.  RE: Standardizing Blockchain

    TM Forum Member
    Posted Feb 27, 2018 01:13
    ​Thanks Brian,

    This actually helped me understand a lot more things about Blockchain, where can we use it in business and especially me working on Reporting, narrowed down my question list as well. I actually read in one of the forum that a Block is restricted to 20GB at the moment(In case of bitcoin), because of which I was curious about the size constraint, but as you said, theoretically it can be much more.


    ------------------------------
    Siddharth Mohapatra
    BT Group plc
    ------------------------------



  • 10.  RE: Standardizing Blockchain

    Posted Feb 27, 2018 03:53
    ​@ Brian

    What are your thoughts of the industry trend of IPFS and Blockchain?

    Thanks
    Raven ​

    ------------------------------
    Ravendran Naicker
    Liquid Telecom South Africa
    ------------------------------



  • 11.  RE: Standardizing Blockchain

    TM Forum Member
    Posted Mar 04, 2018 11:40
    @Ravendran Naicker​​
    IPFS and blockchains is an interesting combination. Might solve some problems, or create other problems. I really haven't touched IPFS since 2014, when I found an issue, raised a bug, and moved on to other things.

    I believe that when accessing a file stored on IPFS, the node stores "content it is interested in" locally. Assuming that your referring to my comment that a blockchain could theoretically become huge, I'm not sure how IPFS will handle files larger than your local storage capacity. But it's easy to test.

    1. Create an IPFS node, add (or find) a large ISO file, and hash the file.
    2. Create an IPFS node without enough free space to store the entire ISO file, and hash the same file.

    ------------------------------
    Brian LaVallee
    INVITE Communications Co. Ltd
    ------------------------------



  • 12.  RE: Standardizing Blockchain

    Posted Feb 27, 2018 04:49
    Hi Brian

    Thanks for your explanation of the use cases for blockchain in a telco environment. Just trying to understand why you think call detail records or syslog, mrtg should be part of the blockchain data set? I am trying to understand what scenario other than monetary transactions such as mobile money or e-wallets should seriously be affected by blockchain. It would be huge if we try to include all customer and commercial information under the blockchain scope, so in your opinion what is something which should be mandated to include under telco blockchain and which brings real value to the telco in terms of either saving cost or increasing productivity or meeting some compliance requirements (like GDPR)? What factors should be considered while doing a cost vs benefit analysis in terms of shifting any existing/new non-monetary data or process over blockchain?

    Additionally I believe having a blockchain network (private/public/hybrid) includes a cost and unless its mandated by the governing authority or sponsored by the regulator or telco itself, who is going to pay for the resources, and unlike bitcoins as incentive for the miners, what will be the motivation for this network to dedicate resources (storage/cpu etc) for this telco blockchain?

    Thanks,

    ------------------------------
    Chaitanya Priya
    digiCaaS Consulting
    ------------------------------



  • 13.  RE: Standardizing Blockchain

    TM Forum Member
    Posted Mar 04, 2018 11:08
    Edited by Brian LaVallee Mar 04, 2018 11:44
    Hi Chaitanya,

    While I did mention there are some valid reasons, the point of including call details records, syslog, or MRTG in a blockchain was intended to push the extreme boundaries of blockchain technologies. The thought experiment was using enormous amounts of common telco data. But if it helps you understand, here are some possible scenarios for the aforementioned datasets.

    Call detail records are key to revenue, doubt I have to mention how important the data is. Any large carrier will have multiple systems generating CDR data, which is aggregated (by various processes) on some central system for invoicing. Beside the usual benefits of using a blockchain, individual system that generate CDR data could simply push data to a blockchain. No need to pull or push CDR data from multiple systems, the blockchain would contain the aggregate data for all systems, and an invoicing system could just access the blockchain for up to date information.

    In regards to syslog data, it's hacker 101. After a system is compromised, disable syslog, then remove any record of your activity. This includes removing system logs. While an external syslog server may be sufficient to capture unauthorized access, a seasoned hacker 'may' target the syslog server to remove any traces of their activity. With blockchain technologies, the records are immutable. A hacker would not be able to remove all traces of their activity.

    When it comes to MRTG data, SLA is already a use case category for blockchain technologies. MRTG data would realistically be the "measurements and events" used for reporting the status of a service. The IBM example discussed earlier in this thread shows another example of MRTG data. GPS position, temperature, humidity, and the other bits of information all fall under the basic MRTG umbrella. The blockchain would be a trusted source of data, to be used by all parties to confirm adherence to the SLA.

    I see the sweet-spot for telco use of the blockchain being Command, Control & Intelligence (C2I). Where the current block in a blockchain could contain instructions for devices to perform and/or devices could publish state information to be analyzed by external systems.

    While blockchain technology is capable of efficiently broadcasting messages, to any device that's listening for something new in the latest block. What a blockchain is best at handling are ledger transactions, the plus one/minus one (+1/-1) forms of data. Minutes of usage, interface statistics, inventory counts, and obviously financial data. Yet, there is also a serious drawback.

    A blockchain is not an efficient way to store information. It's not a database, there are no indexes. While analytical software might be able to index the data, a blockchain could also be used to populate a database. Finding (the current balance) in a subset of data, requires that the entire blockchain is read from genesis through to the current block. IBM used their Watson AI to analyze for specific data. To find a different subset of data, the whole blockchain has to be read again. This is in contrast to bitcoin, where the client application ONLY tracks the subset of data specific to one (1) wallet.

    So what in telco should use a blockchain? Something that brings value, increases productivity, or satisfies compliance requirements? The deciding factor is, what information should be shared with a large group. Outside of the telco. The key advantage, is the distributed nature of blockchain technologies, so public datasets are best.

    The most obvious telco dataset would be tariffs. The rates offered by various long-haul carriers, that are a deciding factor in route selection. A carrier publishes their current rate (in a TMForum defined format), it's distributed to all the clients of that blockchain, and LCR processes 'could' automatically reroute calls to use a cheaper long-haul carrier.

    Another use I can think of is, putting LNP data in a blockchain. But there are a number of political and financial complications, so let's not go into those details. Maybe it would work for locations planning to deploy LNP in the future, not where an LNP infrastructure has already been established.

    Some other points to consider: Updated data has to have a timely application, when the latest data point took effect has to have value, and historical information has some intrinsic value.

    When you look inside a telco, there are not a lot of datasets that are shared throughout the whole organization, much less with external parties. Most datasets only apply to a specific section, or small group of sections. So using blockchain technologies to share data, where other methods are sufficient, just doesn't make sense.

    While dedicated resources do have costs, they're small when compared with the development cost of changing OSS/BSS applications to use blockchain data. But in the tariff case mentioned above, carriers and clients could justify the cost of maintaining a blockchain without tokens. Since the blockchain is beneficial for all the participating members.

    ------------------------------
    Brian LaVallee
    INVITE Communications Co. Ltd
    ------------------------------