This past weekend, the Vaulta node operators gathered for an open discussion, moving beyond standard updates. The meeting covered a lot of ground, touching on how to manage price feeds, a new system for resource providers, and some bumps in the road with how nodes connect to each other. They also talked about how transactions move through the network and some ideas for making things run smoother. It was a good chance to see where things stand and what needs attention to keep the Vaulta network strong.
Key Takeaways
-
The move to a new system for oracle price feeds is happening, with $A-$BTC and $A-$USD pairs already active. Price feed providers need to get ready and coordinate their switch.
-
A new framework for resource providers is out, making it easier to manage accounts and deploy the system with a single file.
-
Getting enough Block Producers (BPs) to use the new gossip peering system is still a challenge, and manual setup is currently needed to join.
-
The Vaulta network's architecture is being reviewed, with attention on where transactions can get slowed down.
-
There's talk about running nodes only on finalized blocks to simplify operations, though this might affect some uses.
-
The role of speculative execution in processing transactions is being clarified, with ideas about specialized nodes.
-
Coordination among price feed providers is important to avoid issues when the new pairs system goes live.
-
The current BP gossip peering might grow to help discover more nodes in the future, but that's not the main focus right now.
Oracle Price Feed Migration to Pairs System
The transition of oracle price feeds to a new pairs system is underway, but some questions remain about the implementation status. Detroit Ledger Tech, for instance, has asked for more clarity on when price feed providers should make the switch.
On the positive side, the $A-$BTC and $A-$USD pairs are now active. This means that two key oracle approvals, from Aloha and Greymass, have been secured, allowing these pairs to function. However, coordination among price feed providers is still needed. Currently, oracle operators haven't started feeding prices into these new pairs. The main concern is that a simultaneous launch by multiple providers is necessary to stop potential price manipulation.
Adding to the complexity, the process for registering new oracles is still manual. This involves custodians, such as Aloha, Rio, and Titan, whitelisting new providers before their price feeds can be approved and registered.
Delphi Implementation Status Questions
Detroit Ledger Tech has raised questions regarding the timeline for Delphi oracles to adopt the new pairs system. They are seeking clarification on when price feed providers can begin the cutover process.
$A-$BTC and $A-$USD Pairs Now Active
The $A-$BTC and $A-$USD pairs have received approval from both Aloha and Greymass oracles, marking a significant step towards their operational status.
Coordination Needed for Price Feed Providers
Discussions highlight the requirement for multiple price feed providers to go live with the new pairs concurrently. This is to prevent any potential for price manipulation and ensure market stability.
Oracle Registration Process Remains Manual
Prospective oracle providers must undergo a manual whitelisting process by designated custodians. Aloha, Rio, and Titan are currently fulfilling these custodian roles for price approval and oracle registration.
Resource Provider Framework Release
Greymass has put out a new framework for resource providers. This system is meant to handle account resources automatically. Think of it like this: instead of needing a bunch of scripts to keep things like oracles running smoothly with enough CPU and NET, this new framework does it all in one go. It's a big step up from their old Node.js setup, making things more portable and easier to manage.
One of the neatest parts is the deployment. It all compiles down to a single executable file. This makes getting it up and running much simpler than dealing with multiple scripts. The functionality is pretty similar to what they had before, especially when it comes to managing resources based on certain thresholds, but the packaging is a lot cleaner. This should make it easier for more people to set up and maintain the necessary resources for key accounts on the network.
BP Gossip Peering Progress and Challenges
Getting Block Producers (BPs) to talk to each other directly through gossip peering is still a work in progress. We've seen some adoption, with operators like Detroit Ledger Tech turning it on, but it's not quite enough yet. The main hurdle is reaching a critical mass of nodes actively using the gossip protocol. Without enough participants, it's hard for new nodes to find and connect to others reliably, leading to these small, disconnected groups of peers. It's kind of like trying to start a conversation in a room where only a few people are talking – the message doesn't spread very far.
Right now, if you want to join the gossip network, you still need to manually connect to at least one peer that's already part of it. This bootstrap process is a bit of a manual step that we're looking to improve. We're discussing different ways to handle these initial connections, like maybe a central point people connect to first, or a more spread-out method. Looking ahead, there's talk about possibly using this gossip system for more general peer discovery beyond just BPs, but that's something for down the road. The focus now is making sure the BP-to-BP communication is solid.
Network Architecture and Transaction Flow Discussion
Discussions around the network's structure and how transactions move through it have brought up a few points.
Transaction Relay Bottlenecks Identified
People have noticed that getting transactions from public API nodes to the actual block producers can be slow. This seems to be a reason why the blocks being made don't always have as many transactions as they could. It's like a traffic jam for data trying to get to the front of the line.
Finalized Block Mode Considerations
There was a good amount of talk about nodes only working with blocks that are already finalized, especially with the Savannah consensus. This could make things simpler for running nodes. However, for some uses, it might mean a bit more waiting time for information to show up.
Speculative Execution Role Clarification
We also talked about whether every single node needs to run speculative transaction executions. Some think it might be better for the network if certain nodes were set up to do just that. This way, nodes could focus on specific jobs, potentially making the whole system run smoother.
This article was created with support from AI-driven technology, drawing on multiple reputable sources. The final content has been thoroughly reviewed and edited by BlockzHub's editorial team to ensure accuracy, clarity, and coherence. Original reporting sources are credited whenever appropriate and as required. The opinions expressed in this article do not necessarily represent the official views or positions of BlockzHub. This article is intended for informational purposes only and should not be considered financial or professional advice. Investing involves risk, and you should consult a qualified financial advisor before making any investment decisions.