One of the most proposed upgrades to brc-20 is optimization.
Initially conceived as a proof-of-concept experiment, little consideration was given to optimization, leading to valid criticisms. Therefore, as one of the least controversial topics, and with L1F now implemented, we believe that optimization should be prioritized in the upcoming updates to brc-20. Please use this thread to propose, discuss the pros/cons, and develop techniques to enhance the optimization of brc-20.
I support an “upgrade” to CBOR as now the human readability benefits JSON provided have been abstracted enough across the various ecosystem UIs. It would make sense long term to move to a more compressed data standard.
IMO metaprotocols like BRC20 should utilize flags or fields within an inscription envelope, or even define alternative envelopes entirely.
I would like to get Psifour’s opinion on the specific metaprotocol field implementation suggested by Casey. I believe that he thinks it could be handled more elegantly, so I would urge caution on embracing that field at this time.
I would be happy to work towards standardizing a new and more efficient binary representation of BRC20 inscriptions. Judging by how many inscriptions transactions are in the mempool, i think this would go a great distance towards improving conditions in the fee market. It would also make BRC20 much cheaper to transact.
Hello @conduition, thanks for your message. We created L1F to provide a platform for contributors like you to actively influence and shape the standard. We want to be transparent about our progress: updates like optimization haven’t been advanced yet because our primary focus has been on establishing a robust and stable foundation for indexing and validation in brc-20. As we are nearing the completion of this phase, it’s becoming more practical and safer to coordinate and execute these updates.
Given that a large proportion of the mempool and block space is currently being taken up by BRC20 transactions containing a lot of unnecessary JSON data, i’d say optimization should be done before trying to stabilize anything. The current protocol shouldn’t become a robust standard given how inefficient it is.
@domo where would be the right place to propose changes? Is there anywhere I can file a PR against the spec?
This is out of scope, but a slightly more efficient form of BRC20 has been concocted in the form of CBRC20: blog [dot] ordinalhub [dot] com/what-is-cbrc-20/ - however this is still not as efficient as direct binary encodings.
Hi Domo，Would you please take a look at the BRC20-E proposal from BNSx？Thanks
The BRC20-E Proposal.
One of the key innovations of BRC20-E is the addition of the “e” field in its JSON structure, enabling extension.
It also includes the “d” field for BASE64-encoded data, which can be decoded using the protocol’s protobuf design.
Efficient Data Usage: BRC20-E smartly minimizes additional data submissions to the BTC. Less data means lower costs, making your transactions more efficient and wallet-friendly.
Unified Protocol Design: With its uniform protocol structure, BRC20-E ensures seamless integration and understanding across the #BRC20 ecosystem. This unified approach translates to more streamlined operations and, in turn, cost-effective transactions.
Immutable and Reliable: Once deployed, BRC20-E’s protocol extensions are set in stone on the BTC network. This immutability guarantees stability and consistency, leading to fewer disruptions and associated costs.
Empowering the BTC: BRC20-E not only enhances the existing functionalities of the BTC but also opens up new possibilities for tokenization, all while keeping your gas fees low.
The full proposal link please check their twitter account
Twitter @thebnsx
Hi Domo，Would you please take a look at the BRC20-E proposal from BNSx？Thanks
The BRC20-E Proposal.
One of the key innovations of BRC20-E is the addition of the “e” field in its JSON structure, enabling extension.
It also includes the “d” field for BASE64-encoded data, which can be decoded using the protocol’s protobuf design.
Efficient Data Usage: BRC20-E smartly minimizes additional data submissions to the BTC. Less data means lower costs, making your transactions more efficient and wallet-friendly.
Unified Protocol Design: With its uniform protocol structure, BRC20-E ensures seamless integration and understanding across the #BRC20 ecosystem. This unified approach translates to more streamlined operations and, in turn, cost-effective transactions.
Immutable and Reliable: Once deployed, BRC20-E’s protocol extensions are set in stone on the BTC network. This immutability guarantees stability and consistency, leading to fewer disruptions and associated costs.
Empowering the BTC: BRC20-E not only enhances the existing functionalities of the BTC but also opens up new possibilities for tokenization, all while keeping your gas fees low.
The full proposal link please check their twitter account
Twitter @thebnsx
the BNSx community here made an extension proposal for BRC-20 protocol which named BRC20-E Protocol, we did some work to solve the protocol continuity issues and saving gas problem. The details could see in our github’s proposal repository,
i was thinking a proposal that both decentralize the indexer and check the state more faster as BRC20 not supporting the global state, wallet need to construct the account by themself.
Efficient Data Usage: BRC20-E smartly minimizes additional data submissions to the BTC. Less data means lower costs, making your transactions more efficient and wallet-friendly.