I had fun writing yesterday's post.
I'll just try that again. I start somewhere and see where it takes me this time.
To start my day on Hive, I dump this to ChatGPT:
ChatGPT gives me this:
Overall, the diagram seems well-organized and thorough, which would be necessary for managing a complex system like a blockchain or a database with a fork management component. It serves as a comprehensive guide for developers, engineers, or anyone needing to understand or work with the system's internals.
I am anyone.
I kind of understand what it's meant to do.
I understand that managing reversible blocks is quite the challenge. Personally, I wouldn't even touch that. The furthest I would go, would be to inform the users of my product, that their transaction has been signed, included in the blockchain (after getting a reply from rpc) and that my app is waiting for the block to become irreversible and then move on. This would introduce a delay of a minute or something (don't know how long a block takes to become irreversible, I just guess it's a full round) for every single move that a user can do with my app. Kind of sucks, but that just comes with building stuff for a blockchain, I guess.
I feed the last paragraph to ChatGPT:
Your perspective on handling reversible blocks highlights an important aspect of designing blockchain applications: the trade-off between immediacy and finality. Your approach to inform users about the state of their transactions is a practical one, emphasizing transparency and setting expectations for the inherent delays in blockchain confirmations.
[...]
[...]
Your commentary suggests a pragmatic and user-focused approach to building on blockchain technology, where the reliability of transactions is not compromised for speed. It's a conservative strategy that could serve well in high-stakes environments where the assurance of transaction finality is paramount.
I don't quite know what would cause a block to be 'reversed'.
I assume that Hive would try to keep valid transactions, and only dismiss the part, that would make a block invalid, in case of reversal...
My approach so far was this:
- Build a transaction client-side and send it to a public Hive node.
- Wait for confirmation from the node, which would include a transaction id, should it go through.
- Make the client send the tx_id to my backend
- Make the backend query a public node and search for the transation (with 'reversible' as parameter because I hope that's good enough)(I also use a queue and try mutliple times until it finds it or times out)
- Make the backend send confirmation back to the client
I feed that whole block of text to ChatGPT again:
In blockchain systems like Hive, a block can be reversed or "orphaned" due to a fork in the blockchain. This happens when two miners produce blocks at similar times, and the network must choose which chain to continue. Eventually, one chain becomes longer (has more proof-of-work or stake, depending on the consensus mechanism), and the network reaches a consensus to adopt this chain. The blocks in the shorter chain are then orphaned, and transactions within them may be dropped or included in new blocks on the longer chain.
[...]
Yeah, it doesn't know the details of Hive, we don't have 'miners', but if you replaced it with 'signers' (witnesses in our case), I think that would be correct.
I didn't know about the 'longer chain' thing, but that makes perfect sense. Simple & elegant; I like it.
[...]
Your method seems to prioritize ensuring transaction finality before acknowledging the transaction as successful to the user, which is a sound approach in blockchain applications where irreversibility is a critical feature.
Moreover, I might have to query a hive-engine node, instead of a Hive node.
Most people that I have helped or have built with, use hive-engine... Because token=$$$.
I know ChatGPT wouldn't know how that would work, so I'll leave it at that.
How reversible are hive-engine blocks anyways?
For my own app that I am designing right now, I use Hive L1 only, so I am good for now...
This was a detour. I am still wondering if I need HAF. I don't think I do.
My approach would allow me to build a DB, that is very light and only includes the very specific transactions, that I need for my app.
My backend only queries for specific tx_ids and I can query public nodes (If needed via queue and if needed I can rotate through different public apis to keep the traffic low for individual nodes.)
ChatGPT gives me a suprisingly detailed analysis:
[...]
In summary, if your application's current requirements are met by querying public nodes for specific transaction IDs, and you don't anticipate needing the additional capabilities provided by HAF, then your current setup may be appropriate. However, if you expect to scale up significantly, require real-time processing, or need to interact with a wider set of blockchain data, then investing in HAF might be beneficial.
It's also worth considering the long-term vision of your application. If you foresee a need to quickly adapt to new requirements or a significant increase in transaction volume, HAF could provide a more robust foundation to accommodate that growth. On the other hand, if the application is expected to operate within the scope of its current functionality, the added complexity of HAF may not be necessary.
If I could estimate the scale of a service like that, I wouldn't be here.
That is outside of my experience, well above my paygrade.
I am building what I am building to gain experience at exactly that, and to make some profit for myself while doing so.
I am trying to build something worthwhile, that I hope users are happy to pay me for.
I am fine with limited scope. For now, I think my 'naive' approach will work.
I expect some profits, but not enough to justify operating my own HAF instance and everything that comes with it.
My mood:
Reversibility is causing me a headache.
If I ignore it completely and conveniently only query for 'irreversible' the user experience might be slow, but for my app that's ok. I'd rather spend time gamifying the user experience than making it all real-time and super fast.
Realistically, even if my app is a big success, I will be handling a peak of some 1000 txs per day.
I just had the idea: I could dynamically change the price per 'move' on my app, to keep peak traffic low, or in case it goes all crazy, to justify spending money for someone to help me.
Scaling the price procedurally on my end is a lot easier for me than to go through all that hassle with HAF.
I feel like I just made a big leap and I need a coffe and a smoke.
I love ChatGPT.