[2018.4.20]Bluzelle Telegram Live ft. CTO Neeraj Murarka
Discussion on Bluzelle DB security, performance & data integrity from a technical perspective
We are glad to have our very own CTO Neeraj Murarka hosting this week’s Bluzelle Telegram Live. During this session, Neeraj explained our upcoming “Lovelace” release in more details and addressed lots of technical questions coming from the audience.
About Neeraj Murarka
Neeraj is the CTO of Bluzelle. He is a software engineer and computer systems architect with over 20 years expertise in cutting edge technology. He has worked on projects for Google, IBM, Hewlett Packard, Lufthansa, Thales Avionics, and Zynga. Some of Neeraj’s largest projects include: locking down of modi ed Android OS for retail markets; multicast UDP satellite-based music streaming systems, mobile app for blockchain startup “Zeroblock”; design and development of secure and FFA-approved systems for Airbus and Boeing commercial aircraft.
Discussion Summary
Q: What sort of operations will be available in Lovelace? And will stakes be required in the beta?
A: We will support CRUD at both the web-sockets level and Javascript level. Stakes are not required. It is a test-net, so stakes will come later when the network moves to production.
Q: What further functions are in the plans for post-Lovelace?
A: That would be in the Bernoulli release, which follows Lovelace. Key things there will include the emulator, bootstrapping, full CRUD at the NEO and Ethereum level, and GUI client tools.
Q: Will the Lovelace beta be available to public after the hackathon?
A: Apart from the emulator, which is kept internal, the code for the Lovelace beta is all on Github in our public-facing repository and therefore is available to the public.
We will also be making binaries available to the public soon.
Q: (In relation to the previous reply) Could you explain the difference with or without the binary?
A: If you have the binary, you do not have to set up a build environment and get the code and go through the steps to build the binary. The binary is like a Windows “exe” file, and is what you need to actually run a swarm node. So, to make things easier for users, we try to put binaries out.
Q: Why did you choose to build BLZ Tokens on the Ethereum network?
A: BLZ token follows the ERC20 standard, and the reason for this decision is to have maximum compatibility with the rest of the crypto world.
Q: Do you think “Cryptocurrencies” could supersede Sovereign Debt as a financial instrument?
A: It is a possibility. Cryptocurrencies really speak the truth about the state of a ledger and who owes what, and so it could introduce a level of transparency that is beneficial but also possibly scary for national governments. Having been involved in politics myself, I would love to see something like this happen, but am also aware of the fact governments can and will stand in the way of things that can threaten the power structure.
Q: Do you think it will be possible to link smart contracts to a Bluzelle database in the future?
A: Indeed, smart contracts are one of our first targets in that we are building integrations so that smart contracts can use the Bluzelle database.
Q: Where do you see Bluzelle 2 to 5 years from now?
A: We are the leader in decentralized databases with a massive market share not just for dApps but also for applications in other spaces including mobile, enterprise, etc.
Q: Do you realistically see anyone not needing to use this service in a data-oriented future?
A: There are always use cases that wouldn’t apply. If you have a very secured and “air-gapped” environment like a nuclear reactor or even an airplane in flight (that is disconnected from the network) or a situation where a company has to store all the data physically on its own servers in its own offices, a decentralized network would not be as applicable.
Q: What is your opinion of Zilliqa? Will you be working with them?
A: Great company. We are collaborating with them. I’d love to see blockchains other than Ethereum-based ones come up that improve upon its own shortcomings and give users the choice. Competition is a good thing.
Q: Who do you consider to be your competitors?
A: People often ask us about Storj and Filecoin. These are file-storage services and are complementary to Bluzelle, and not competitors. The key one that comes to mind is BigChainDB, which claims to be an immutable database that has blockchain charateristics.
Q: Are there any synergies for Bluzelle to work with Golem or any form of decentralised computing? How would that look for future computing?
A: I do have a vision of a fully decentralized stack where applications with heavy CPU computations would use Bluzelle and other decentralized services to have a truly decentralized stack.
Q: How would other blockchain project use Bluzelle and what is the difference without it?
A: BLZ is an ERC20 token. Strictly speaking, any project can use it as it is decentralized and Bluzelle has no means to control what it is used for. That having been said, the point of it is to drive the crypto-economy of Bluzelle and enable consumers to use the database and producers to be incentivized to provide resources to it.
Q: How hard would it be for the world to integrate to BLZ outside of the current blockchain infrastructure?
A: Keeping in mind that Bluzelle is not built on top of the Blockchain and is in fact a network of its own that uses swarming technology, it is actually very straightforward for the non-blockchain world to “talk” to the Bluzelle network. Our nodes in Lovelace will already have web sockets and JS support, both of which are very standard interfaces that even non blockchain applications can easily integrate with. Interestingly, integrating with blockchains is where the more complex integrations happen.
Q: How do the nodes exactly work? What resources of your computer would be used to run one?
A: A node’s primary resource is the storage space needed to store data. So, this could be a hard disk, cache memory, regular memory, or even a tape drive. But the other resources also needed are CPU, and network connectivity. All of these are used to power a Bluzelle node, when you are a farmer, enabling you to store the data for the swarm(s) you are in, for which you get compensated in tokens.
Q: There was this pretty interesting article that came out, about what happens in an Ethereum chainsplit. Many coins on ERC20 network would be affected in such a case since it means a clone for every coin available. This would also affect tokens such as stablecoins. Any take on how this might affect BLZ, BLZ database and how Ethereum dApp developers might experience issues with BLZ in such a case?
A: We are aware of the fact Bluzelle has a BNT token that will help to mitigate issues stemming from an Ethereum network fork. We’d have to explore best practices to deal with such splits. I have looked at it briefly with respect to Bitcoin and there are certainly algorithms to deal with such situations.
Q: How long are the data stored for Bluzelle?
A: Contrasted to blockchains, Bluzelle is mutable, where your data will not naturally persist forever. The short answer is your data will remain stored for as long as you (the data owner) and others (data consumers) are keeping the data fresh by means of usage and paying for the data storage, through a TBD mix of read costs and write costs. We are still determining the best combination that meets everyone’s needs best.
Q: In terms of storage duration and regulations, is it going to be in general, or would you apply country specific laws? For instance, some countries only allow storage of data up to 7 years.
A: In general. It is not likely that country-specific laws would come in automatically to govern mutability rules, as this would not work with a swarming approach where the nodes are all over the world.
I designed and architected Bluzelle with the philosophy that a database is a sophisticated and powerful service that can store your data for you with security, performance, scalability and reliability in mind, but where “business logic” should not be integrated natively into the db. In this vein, it would be upto the application developer (data owner) to decide how long they want to store the data, and of course, given Bluzelle is mutable, they have the option to remove it at any time, as their laws’ requirements.
Q: How many different nodes do you expect would store a shard of data?
A: To expand on this great question, every node in a swarm stores the same shard of data, and your question is how many nodes are in that swarm. The simple answer is we aim to minimize the number of nodes in a swarm, so that we can still achieve 100% “mathematical certainty” that the swarm will persist even if nodes crash. The actual literal number is not yet determined. If a swarm has reached this minimum, new nodes would join other swarms that are more in need, or a new swarm might take birth all of which has the goal to maximize space on Bluzelle will still maintaining our key metrics.
Q: Are there any mechanisms to handle a possibility of all nodes being full? E.g. the database has reached maximum capacity.
A: In terms of multiswarm (which is the end goal), it wouldn’t technically happen both initially (since Bluzelle will run many nodes and has the resources to add nodes as needed) but also because a proper crypto-economic model would dictate that as nodes get full, prices of storage will go up, and so more farmers will join, and new swarms will get created that dilute out the data that is being concentrated in existing swarms.
Q: How do you test new nodes for general practicability/security?
A: They will face “proof” challenges in a non-deterministic way. For example, a node that comes up and claims 3 GB of free space would have to prove that they actually have this much space, and face an economic penalty for making such a claim and not being able to prove it. Security is would ultimately be done right when the data is being stored, using industry-standard algorithms that ensure that nodes storing your data do not have the technical ability to steal or divulge your protected information.
Q: What is the limiting factor of a decentralised DBMS from a technical perspective? How does the speed of reading/modifying the data compare to centralised systems?
A: Performance of a database server sitting on the same LAN as your client is generally going to be much greater than any sort of decentralized or cloud approach. That’s just simple physics :). If you have an application that needs LAN-based network speeds or cannot handle (for example) the round trip time for getting data in a parallelized fashion from nodes that might be in your local geographical area, then I would consider your application to have very specific performance needs and be more of an outlier.
Q: When will your team release the exact system requirements to be a Producer?
A: The “exact system requirements” will be released more as guidelines of what the minimums will be. As you can imagine, a swarm is only as “strong” as the weakest node in that swarm, so we will have minimum requirements on how much space and network speed you need to have to join the network but also what you probably want to have ideally to be an effective producer, getting better returns for your participation.
Q: (In relation to the previous question) Will the swarms be grouped into clusters with different performance abilities?
A: No. Swarms are meant to store data that is partitioned using hashing functions, so that would be how swarms are differentiated. Within a swarm, certainly there will be a heterogenous mix of nodes with different resources and performance abilities.
Q: (In relation to the previous question) So every swarm has to hit a combined minimum benchmark metric of available storage and computing power?
A: Well, it is not quite “combined”. It is more about ensuring that no single node in that swarm limits the swarm, so at the node level, every node must meet minimum requirements but some nodes could vastly be better than those requirements and would therefore be more likely to end up serving requests for data on that swarm, than say nodes that have bad connectivity or low karma.
Q: I assume people would want to rent out their computers to earn BNT/BLZ right? So they would need to run a client, how would this client look then?
A: Yes. We will have a UI that goes with the daemon (which is what you run to “rent out” your computer) so that you can easily configure it and observe it. The UI in Lovelace will be text/console-based but once we go into later releases, we intend for the interface to be super user-friendly so that even non-techs find it welcoming and straightforward.
Q: What happens if someone store illegal things in Bluzelle Database?
A: It is a complex question. Bluzelle has a major advantage that blockchains do not have — the data is mutable and can be removed if and when necessary. My belief is that like any other storage service provider (such as incumbents on the cloud), if someone stores something illegal, they can be required by authorities to remove that data and of course, Bluzelle has the ability to actually have it removed.
Q: Is Bluzelle able to identify where the data is stored?
A: Yes and no. The network knows where data is stored in a decentralized way but it does not give out information on the geographical whereabouts of nodes. What is important is that whenever a request comes in to remove data, it will be removed from all the nodes storing it.
Q: Would data stored on Bluzelle be lost?
A: Data wouldn’t be lost in our model. The design of swarms is to provide a mathematical guarantee (as in effectively 100%) that your data cannot be lost. If you actually delete your data by mistake, that is not something we would initially support.
To Get Started with Bluzelle
Get-Started Guide|Website| Whitepaper(English)
Never Miss An Update By Following Bluzelle’s Channels
| Newsletter | Telegram | Twitter | Reddit | Github | Developer Slack |
