Hey, Jackal Community! It’s an exhilarating time in our journey as we continue to push the boundaries of what’s possible in the world of decentralized data storage. Today, we’re here to chat about an exciting potential upgrade to our protocol that could dramatically enhance the Jackal experience.
The Jackal Protocol is buzzing with activity! We’ve even outpaced Sia Coin in terms of active file traffic. That’s a pretty fantastic achievement in only two months. But with great growth comes great challenges. Our proofs, though larger than Sia’s, go through a much smaller proving window, and we have more data coursing through each of these windows. We’re working on making them 20x smaller with ZK proofs, which will take a little more time.
Currently, every hour is a proving window for JPOP (Jackal Proof of Persistence). If a provider misses three of these windows, their storage deal is broken to make sure the network always has 3x redundancy. With the current sheer volume of files being processed, it’s like trying to squeeze a watermelon through a garden hose – this slows down the network and is not the most user-friendly experience.
So, how can we turn this watermelon-sized challenge into a grape-sized one? The core developers are considering a few tweaks. The first is to double the size of the burn window. This does slightly lessen our security margin, but don’t fret – it’s still four times tighter than that of SiaCoin or Filecoin.
The second part of the plan is to stretch the window time to three hours instead of one and require only two misses to trigger a burned storage deal. This would mean providers send transactions less often, giving them a bit more breathing room. But the network is still strong – this also means storage providers need to be more vigilant to avoid a deal burn.
These changes should ease the bandwidth demands on validators and increase the chances of providers successfully proving storage deals. All of this before we even roll out the ZK improvements we’re working on!
Here’s where the Jackal Community comes in. We’re putting this proposal up for a vote. It’s your chance to weigh in on the future of our protocol.
Vote ‘yes’ if you agree with our bandwidth reduction strategy and feel the need for a scale-up. Vote ‘no’ if you disagree with the proposed methods or don’t see the need for scaling at this time. If you think this proposal could harm our beloved Jackal Protocol, you can cast a ‘no-with-veto’ vote.
We can’t stress enough how vital your voice is in this decision. The Jackal Protocol is a community-driven platform, and it’s your insights and opinions that shape the path forward.
Keep the conversation going, keep questioning, keep challenging, and keep innovating. Together, we’ll continue to redefine the limits of decentralized data storage.
Let’s build the future we want to live in.
Vote here: https://ping.pub/jackal/gov/5