Recap of Bluzelle Youtube Live
Full presentation, demo and summary of Q&A
Last week, we hosted a Youtube Live Streaming where we presented the Bluzelle Cache and did a live demo. If you did not catch the live session, you can play back here:
Below is a summary of Q&As during the live session.
Product & Tech:
Q: What’s the main problem that Bluzelle Cache is trying to solve?
A: Providing managed performance and high availability data caching for games to a global customer base.
Q: Besides setting up new data centers globally, aren’t there other current solutions that solve the problem in global performance?
A: Currently people have to set up replicated servers of their own, in data centers in different locations, one by one. Without decentralization, data cannot automatically be replicated globally and at the edge with the availability and speed that Bluzelle offers.
Q: Gaming companies use different gaming engines. Example would be Unity. Unity uses C#. Does Bluzelle have integrated solutions for multiple languages? Or a gaming company that has a Python API as their backend?
A: We are building language support for multiple languages including C#, Python, JS, C++, and others. This is the first step and once this is done, Bluzelle can be integrated into Unity. Unity uses C# and one of our major goals is support for languages for gaming engines and specifically, testing and integration of these languages into those engines, to ensure close-to-zero-friction when developers need Bluzelle.
Q: Is there a template/example to use Bluzelle in a “cache aside” manner as you mentioned?
Bluzelle provides a literal JS code snippet that can be used as an example to place into an existing codebase. Keep in mind that cache-aside assumes you are talking to a database as well as Bluzelle, so our template/example does not provide a full-on 100% copy and paste example but does show how to modify what you have so it is cache-aside and uses Bluzelle.
Q: What did Pavel do during the demo? (Starting from 11:56)
A: First he only used Redis to request for data. After that, he turned on “Bluzelle acceleration” mode, which means, asked Bluzelle FIRST for the data, and if Bluzelle has it, you got the answer, and probably really fast. Since Bluzelle is already all over the place “at the edge”, you will get your data way faster than trying to grab it from Virginia, which is the traditional “non-edge-caching” design of applications.
Q: In the demo, where was the ping from Tokyo to? (Starting from 12:27)
A: That was a full request-response from Tokyo to Virginia and back, for Redis. In fact, it was 10 such requests, in parallel. For Bluzelle it was to a Bluzelle node close to Tokyo. Most likely, a Bluzelle node someplace is eastern Asia. The beauty is the developer does not need to know which Bluzelle node. The network figures this out, automatically.
Q: Is this live now or just a demo?
A: It’s on the live testnet and open to the public to use now.
Q: So if Bluzelle has the data, it asks Bluzelle for the data instead of the DB? Is there a full request — response cycle to Bluzelle first to check if the data exists?
A: You ask Bluzelle and if it has the data, you get it fast. If not, you can ask the original DB you had to begin with. This is “cache aside”, which is a very popular pattern for using cache. The cost of asking Bluzelle for the data first is negligible, as this demo is already showing. It is also asynchronous, so you could optionally ask the DB in parallel if you really want. Bluzelle’s point is to be so available that the time to ask it is negligible. It also enables the benefit that in the likely cases where Bluzelle does have the data, the DB does not get asked. This greatly reduces the burden on the DB, which can be a large savings in terms of cloud resource costs.
Q: Why do you compare Bluzelle to Redis but not MongoDB?
A: The current use of Bluzelle is as a data cache. Our database offering will come later. MongoDB is a full database. So our current goal is to measure ourselves against the leading data cache solution. A comparison to a DB at this point is of limited value.
Q: How does it find the “closest” node? By scanning the server IP location?
A: We are continuously optimizing the connection to the swarm and ensuring that you have the lowest latency connection to the fastest node. As conditions change, the connection will also change to adapt.
Q: Have you tested how long does it take to update all 25 nodes globally?
A: It takes about 875 ms (0.875 seconds) based on our current setup and consensus algorithm. This assumes a worst case scenario in terms of distribution of nodes but also assumes the network is otherwise operating properly without adverse conditions. This will improve as we upgrade our consensus algorithm and improve it iteratively.
Q: Will Bluzelle surpass Oracle?
A: Oracle is an RDBMS. Bluzelle’s current use is as a cache and would work alongside an existing database, in most cases, where it caches data that is centrally stored on Oracle. In short, if you use Oracle or any other database, you are likely to gain many advantages by adding a cache to it.
Q: How is Bluzelle’s pricing compared to Siacoin?
A: We can’t comment directly as Siacoin focuses on a different type of service — file storage. When we compare pricing, we can only do this with our closest competitors such as Redis Cache through Amazon AWS or Microsoft Azure or Redis Labs. Our goal is to offer enterprise features that all software developers can afford regardless of size.
Pricing is indeed important. But what really matters is what the value customers are getting from this price. Given the fact that Bluzelle is auto-managed and taking away lots of the pain points for developers with great performance, the value we bring against our competitors is substantial.
Q: What’s the advantage of Bluzelle compared to IPFS?
A: IPFS is a file storage paradigm and in fact is only the file-storage aspect, without any specific economics tied to it. Bluzelle is an edge caching key value store that also includes the economic system to drive the ecosystem forward with producers and consumers. IPFS and Bluzelle are therefore very different things. It is hard to compare them given how different they are.
Q: How does Bluzelle compare to CDN network?
A: CDN is a content delivery network. The bigger players out there are Cloudflare and Akamai. We always compare ourselves with these companies when we talk to end customers. Cloudflare makes web content load up faster, by pushing it to the edge. Bluzelle can be seen as a data delivery network (DDN) to speed up gaming data by pushing it to the edge. In a big picture, we are similar, while observing that Cloudflare is specific to website content while Bluzelle is for software and application data.
Q: What’s the impact of future 5G or 6G network on Bluzelle? Are there any opportunities or challenges there?
A: Bluzelle is agnostic to the underlying connectivity. We will function over 5G networks and provide the same optimizations that you saw in the demo.
In fact, 5G can create a good opportunity for us as more data is coming into play, which can cause congestion. One of the solutions will be making data centers closer to users through edge solutions, similar to what we are building here. What Bluzelle can do is to help telco networks to run faster by moving data right to the edge and reducing the amount of traffic that flows across networks. These future networks make edge computing more compelling.
Q: What are possibilities of Bluzelle to be powered by mobile devices?
A: Our client libraries will support both mobile and desktop. Furthermore, our longer-term roadmap includes enabling mobile devices to act as producers for the network.
Q: Are you targeting more of mobile gaming platforms or desktop gaming companies? Or agnostic?
A: It actually doesn’t matter. As long as the game has a need for high performance on a global level (e.g. a multi-player game), Bluzelle is a compelling offering. Most of the games which have a global audience will need us.
Q: How much data can a node store?
A: Nodes have a minimum requirement in terms of how much they are willing to “rent out”, in order to join the swarm. This is likely to be approximately 100 GB but will vary by swarm and likely increase over time (some swarms may offer more and some less). For example, if a swarm has a capacity of 100 GB, every node in that swarm needs to offer 100 GB.
Q: If Bluzelle is replacing Redis as a cache, how do you ensure data consistency between Bluzelle and mySQL database?
A: This will be similar to how Redis does it with the various replication methodologies offered by Enterprise Redis. What we are more concerned is to ensure consistency among all the nodes. As more nodes join us, we need to ensure all of them are in good faith and are not bad actors. We have built our own PBFT consensus algorithm to make sure data is updated consistently and bad actors are knocked out of the system. Note that Bluzelle can and often is deployed to a system where it does not replace Redis but rather, vastly improves a system that also keeps Redis.
Q: What blockchain based competitors of Bluzelle is currently up against in the space?
A: Bluzelle is not “blockchain-based”. Bluzelle uses various technologies that blockchains also use, but that is the limit of similarities. There are companies offering blockchain-augmented data stores, such as BigchainDB, but these are typically traditional databases that are augmented by a consortium (non-decentralized) approach to improve that database. This is vastly different from Bluzelle’s edge data cache.
Q: Any specific dates for release of cache?
A: Not set yet. We are inline with our target. We are currently hardening the code base and testing the backend. We want to make sure the product is fully working.
Q: What is Bluzelle’s current main competitor?
A: Redis.
BLZ Tokens
Q: So is it the plan to use BLZ tokens for every operation? (read and write for example?)
A: BLZ will be used once the system goes live. We are looking at the model that is most fair and scales the most effectively. Read and write is indeed one model. The ultimate goal is that the customer is charged with BLZ for data services and most of the revenue will go to producers.
Q: Do I need BLZ to use the testnet now?
A: You do not need BLZ to use the testnet right now.
Q: Will Bluzelle always be ERC20 token or do you have any plan to convert to some other high throughput blockchain like Zilliqa to adopt?
A: BLZ itself is an ERC-20 token so it’s easier for people to use and adopt. We have no plans to switch to other blockchains at this moment unless we see a real need for it.
On the other hand, if there’s any dApps on other blockchains that would like to use Bluzelle as a cache, we will build integrations. By that time, interoperability should be there so that tokens can be swapped out with no issue.
Q: Is there any information on the requirements of running individual nodes?
A: This is still being determined. Initially, nodes will be run by Bluzelle itself, and it is at this time that the actual requirements to be a node will be determined. The chief requirements will be a certain minimum amount of disk storage, RAM, and network latency and throughput. Keep in mind this will be SUBSTANTIALLY lower than what miners require — in fact, we expect Bluzelle to run on machines without even being noticed.
Q: What kind of hardware is expected to be required to run a node? Would I be able to run Bluzelle node on popular NAS such as Synology? If I deploy a linux box on my Samsung S9, would it be possible to run a node on it?
A: This is not set in stone yet but it will be considerably lower than anything that a miner uses. In fact, our design should allow you to be a farmer on your existing machine, transparently.
You can run Bluzelle on any hardware on which the node daemon software can run. Since we are open source, you can even build a daemon to run on your hardware, if needed.
We will have builds for most platforms, so you likely will find that the farming software already exists for your platform.
We probably won’t release an S9 version of the daemon but you could most likely build one and run it on your S9 if you want. This goes for any mobile phone that runs a suitable operating system.
Q: Do we need a static IP for a node?
A: Absolutely not needed. We use Ethereum as a bootstrapping mechanism so that even if you are using dynamic IP’s, that’s fine.
Q: What is the vesting schedule for the rest of the BLZ tokens?
A: We go with our vesting plan that is published before ICO https://blog.bluzelle.com/token-details-announcement-77e33323a720. We don’t have immediate plan to vest them all at the moment. When we start kicking off the product, we plan to reward some of the BLZ tokens to the community as initial incentives to use our product.
Partnerships & Customers:
Q: Who is your target audience? DBA, CTO, backend dev, DevOps?
A: The main initial target here are software developers and associated parties such as their DevOps, DBA, architect, CTO, etc. They typically have or expect a global customer base and therefore will benefit from an edge cache and so they look at Bluzelle.
Q: Which companies are scheduled to test the product in the next few weeks? Are you partnering with any big companies who recently announced their gaming platforms (e.g. Google & Tencent)? Are there any non-blockchain companies?
A: We are in talks with some game companies and network engineers about how the network is designed. As the actual product is coming along, we can demonstrate how it works and how it can connect. The ultimate goal is to have real game companies to sign on to pilot and measure real results. Once we confirm, we will announce in our community.
Cloud-based gaming platforms can be seen as other gaming devices such as Xbox, Play Station, Nintendo Switch, Google Stadia, etc. They still need gaming performance on a global level because customers are from different places. Our goal is once we are able to demonstrate how fast our product is and get some real customers, it makes us stronger to build partnerships with big companies. This will be another target market that we will go after. Seeing big companies entering the gaming industry, we can see how big the market is in this space. And the need for faster performance will be even more critical.
Q: Can you talk about the web3 infra alliance? Are there any POCs or testing being worked on together or has this just been a idealized alliance?
A: We are still early with the Web3Infra alliance. We built a very early POC in December 2018 that demonstrated the use of all the technologies.
Marketing & Community:
Q: Will you conduct such broadcasts on a regular basis?
A: Yes we do plan to make this more regular when we have new key things to show off and new results to publish. If there are other specific parts of the technology that we think will help the community, we will host more sessions like this. We will also involve our CTOs and other team members.
Q: What is your current plan to drive adoption?
A: Right now we are focusing on customer adoption. Having real customers and results will bring in more partnerships and build more excitement for the community. We are kicking off this Youtube live now and we will do more in the future. Once the product is out, we will publish more content on various game developer channels online and attend offline events to attract more customers.
If you find this article useful, please give us some claps 👏👏👏
Are you a developer? Try out Bluzelle via:
npm install bluzelle| Tech Documentation | Deploy to Heroku | Github | Gitter Community |
