Shuken Flavours
Today Shuken has two main solutions to provide services to their users, and both provide different solutions for each problem.
- shuken.io -> this is were managed services have enterprise grade hosting, you can think of it in a more centralized way
- vertical scaled capacity to provide community services
- shuken.network -> this is the unmanaged services that are hosted by the node-runners, using the open sourced code in a real decentralized approach
- peer2peer shared resources provide more resilient services
Shuken Platform components
Shuken Node Dashboard
This open source product is an interface that allows users to access their Shuken Node details as well as the Search and Xpub’s Lens functionalities, using the Shuken Indexer data models.
Shuken Explorer
Umbrella product name for Shuken Search and Xpub’s Lens, that is now being deployed in Shuken Console for direct public access, without the need of a node.
Shuken Console
This product is an interface that allows users to deploy the different Shuken Nodes and Relays offering and the Shuken Explorer. It is our SaaS model (Sovereignty as a Service)
Shuken API
This component enables setting an Open Bitcoin Protocol, as we surface our current rest API endpoints/contracts for public use, allowing new products to be built on top of it.
Shuken Indexer
This component takes care of reading bitcoin data from the RPC json interface provided by Bitcoin Core. It transforms the original data model into a search + tags optimized data model, persisted first in a relational database and then into a distributed search engine
Compared to Electrum or Fulcrum focusing on performance, Shuken indexer focuses on providing resilience, by sharding the information into several nodes forming a cluster, enabling smaller devices to host partial data, allowing other users to access it in a transparent way.
Having a database deployed on a single server has several advantages and disadvantages when compared to a cluster with shards.
PROs | CONs | |
Single server | 1. Simplicity: It’s easier to manage and maintain a single server than a cluster 2. Cost-effective: A single server solution may be more cost-effective for small-scale applications or startups 3. Less complexity: Fewer nodes mean less network overhead, which can lead to faster data transfer | 1. Scalability: As your application grows and the database size increases, a single server may struggle to handle the load, leading to performance degradation 2. Single point of failure: If the server fails or experiences downtime, it can bring down the entire application 3. Limited geographic distribution: A single server is typically located in one data center, which could pose latency issues for users far from that location |
Sharded cluster | 1. Scalability: Sharding allows you to distribute your data across multiple servers, enabling better scalability and handling larger datasets 2. Improved performance: By distributing the load across multiple nodes, you can improve overall application performance 3. Enhanced availability: A cluster provides high availability as if one node fails, other nodes in the cluster continue to function | 1. Complexity: Managing a sharded database is more complex than managing a single server deployment due to the added overhead of coordinating data across multiple servers 2. Higher cost: Running a cluster of servers may be more expensive compared to a single server, especially if you’re using cloud-based solutions where costs can add up quickly 3. Increased network complexity: Sharding introduces additional network latency and complexities when synchronizing data between nodes |
In summary, a single server deployment is simpler and less expensive but has limitations in scalability and availability. A cluster with shards offers better scalability and availability but comes at the cost of increased complexity and potentially higher costs.
From a privacy point of view the public data of the Bitcoin Network continues to be available in the same way as having it deployed locally, just with an optimized data model. Only the public tags are propagated across all nodes, but you can choose to propagate your private tags to the shared data model by publishing them.
From a synchronization speed point of view, even looking at the data size for Bitcoin Core Electrum (1TB for a full node) or Fulcrum (150GB), the data is distributed between nodes and there is no need to waiting for a full re-sync, that could take more than one day depending on hardware and bandwidth. And data corruption for the mentioned services happens more often than expected. There is no data corruption on a sharded cluster approach, as pieces of data have replicas across the nodes, and the replica set can be redefined depending on the number of active nodes available.
Infrastructure (capacity) shared among node-runners can scale to create a user centric data platform, enabling everyone (not just big enterprises) to be `first class citizens` in a peer2peer Shuken Network.
Our Indexer tech is a game changer because not only bring us to another level to Data Availability due to the nature of its distributed model among node runners, but also enables new business models and opportunities for those running it, like having a powerful counter chain analysis (UTXO analytics) right in their node/wallet.
When pairing our Indexer tech with our API, it enables any node/wallet, full or not pruned, to fully leverage it as any other full sovereign node runner.
Final Thoughts
We know well how hard it is to build an ecosystem where the current narrative of “digital gold” (Store of value tech) seems to be the winning one, and that makes infrastructure related tech even less sexy that any other pure B2C one.
We will continue our journey as strong believers that without builders, these industry will be completely hijacked by the “big guys” and therefore we are now embarking a new journey where Bitcoin development within Shuken is just a foundational and core work into what we have planned as freedom tech builders.
Looking forward to help the ecosytem grow where Wallets, Processors, and or anybody who want to leverage a solid node tech beyond just node deployments and builds. Together we are stronger!
Happy Sovereignty!