BEVM｜BTCLayer2 / is on Nostr

"55a234dffef879e59c017fd0a8af7e3780b82b2cdca4098c7d88116a405e00a3cf664082b7ecf73174e84f2e64e9b8bfe37e6cd8c7e0cdf6bce1889e42bc9a24"

Last Notes

2024-10-24 08:21:06

- reply

Keep building Bitcoin Ecosystem.🧡🧡🧡

2024-09-13 07:35:24

What Basic Roles Are Needed to Develop Hashrate RWA?
https://m.primal.net/KoYQ.jpg
Backed by mining giant Bitmain, BEVM has positioned itself to create a "BTC Layer2 ecosystem characterized by hashrate RWA." On July 16th, BEVM, in collaboration with several leading industry institutions and projects, held a hashrate RWA ecosystem brand launch event, sparking considerable discussion about hashrate RWA on social media.
Since this field is linked to hashrate, achieving stable and sustainable development in this emerging sector requires the collaboration of multiple parties. This includes a stable source of hashrate, entities to carry hashrate assets, and ways to bring hashrate on-chain for widespread DeFi applications.
Below, we will discuss five crucial roles in the development of hashrate RWA and their functions.
1. Reliable Hashrate Resource Providers
Reliable hashrate resource providers are the foundation and prerequisite of the hashrate RWA ecosystem. They are responsible for providing high-quality hashrate resources, assisting in bringing these resources on-chain, and acting as supervisors to ensure the authenticity and reliability of these resources.
Bitmain, a long-standing manufacturer of mining machines and operator of mining pools, is a major institution advocating for the development of hashrate RWA. Bitmain's mining pool hashrate and miner community lead globally, providing abundant hashrate resources. Besides the hashrate from mining machines, Bitmain's sole cloud hashrate partner, BITFUFU, also supplies hashrate resources. At the hashrate RWA launch event, BITFUFU stated that it currently manages hashrate accounting for 4.8% of Bitcoin's total hashrate and can directly sell hashrate to numerous hashrate RWA projects.
2. Secure and Reliable Hashrate Asset Carrier Chains
To achieve "RWA" for hashrate resources, a secure and reliable hashrate asset carrier chain is needed. This chain is responsible for converting hashrate resources into on-chain tradable assets—known as PoW Hashrate Assets (PHA)—and providing a secure and reliable environment for transactions and applications.
The BTC Layer2 project BEVM is actively building a hashrate RWA ecosystem. BEVM uses Taproot Consensus as its underlying technical framework, integrating advanced technologies such as Schnorr signatures, MAST contracts, and the Bitcoin light node network. This allows it to securely and decentralizedly extend Bitcoin's functionalities, with top-notch cross-chain custody technology for Bitcoin assets. As a carrier chain for hashrate assets, BEVM offers high security and scalability and is EVM-compatible, ensuring that mature DeFi applications validated by the market can be quickly deployed, providing a secure and reliable development environment for PHA.
Additionally, to promote the development of the hashrate RWA ecosystem, BEVM launched a $10 million support program for the hashrate RWA ecosystem in June this year, aiming to support 10-20 hashrate RWA startups.
3. Hashrate Asset Application Providers
Hashrate asset application providers in the hashrate RWA ecosystem are responsible for developing and maintaining various DeFi tools and applications, enhancing the liquidity and utilization of hashrate assets. Currently, the two main forms of hashrate assets are Tokens or NFTs, which can be further utilized in diverse ways.
BEVM is focused on building a comprehensive hashrate RWA ecosystem and has already attracted several teams related to hashrate RWA and DeFi. Its hashrate RWA ecosystem mainly consists of two parts.
First, hashrate RWA assets can directly enter BEVM's DeFi protocols, using on-chain tools such as DEX, lending protocols, stablecoin protocols, derivatives protocols, and staking protocols to unlock their financial value. Second, DeFi applications can be built around PoW Hashrate Assets (PHA). When hashrate RWA mines PoW tokens that circulate directly on the BEVM chain, these tokens become mineable coins. This new type of hashrate asset mined by miners can open up new DeFi applications. For example, BTC generated from hashrate RWA can be used to build BTC staking and interest protocols, providing miners with more revenue and DeFi innovation opportunities.
4. Hashrate RWA Users
Currently, the global hashrate market is approximately $20 billion per year, with Bitcoin accounting for $17.5 billion. With a large market, on-chain hashrate RWA assets, and DeFi applications, the end-users of the hashrate RWA market, mainly miners and various types of investors, come into play.
They are not only users of hashrate resources but also demanders. This is because traditional miner income models are limited, especially after Bitcoin's fourth halving, where the hashrate requirements have increased significantly. This has led to hashrate being gradually controlled by large institutions and mining companies, making it difficult to realize the actual value of hashrate. Through hashrate RWA, on the one hand, the rich application scenarios in the DeFi ecosystem can provide multiple on-chain revenue models for hashrate RWA, bringing new income sources to the miner community and improving their capital utilization. On the other hand, investors can participate in the mining economy by purchasing and trading hashrate RWA assets, achieving additional investment returns.
5. Hashrate Ecosystem Investment and Incubation Institutions
Investment and incubation institutions can help expand and accelerate the development of hashrate RWA by providing funding and resource support. These institutions can collaborate with technical teams, market promotion, or other industry participants, especially providing resources and opportunities during the early development stages of hashrate RWA projects.
Specifically, besides mining companies like Bitmain, which inherently have advantages in developing hashrate RWA, we also see traditional hashrate institutions and investment funds focusing on this sector behind current hashrate RWA projects. For instance, Compute Labs, a Solana-based RWA tokenization protocol using computational (CPU and GPU processing power) as its underlying asset, recently received a new round of funding from renowned institutions like Protocol Labs, Blockchain Coinvestors, and OKX Ventures. Compute Labs, incubated by Nvidia Inception, plans to build various derivatives based on computational resources.
Conclusion
Although the hashrate RWA ecosystem is still in its early stages, its expansion and practical application scenarios cannot be separated from the collaboration of the five key roles mentioned above.
Bitcoin's fourth halving has significantly impacted the mining industry, and the explosive growth in global AI computing power demand has intensified competition in mining and AI computing power fields. However, this also promotes the further implementation of the hashrate RWA ecosystem. With capital support, leading projects like BEVM are attracting more attention and discussion. The explosive growth of the hashrate RWA ecosystem is just a matter of time.

2024-09-13 07:31:58

Why choose P2TR as Bitcoin's trading script, and how does it boost the development of the BTC ecosystem?
https://m.primal.net/KoYJ.jpg
Bitcoin is the most popular and popular cryptocurrency, but as the network grows in popularity, so does the speed and fees of transactions, and the associated privacy and security concerns are becoming more concerning.
To improve the privacy, scalability, and smart contract processing capabilities of the Bitcoin network, the Bitcoin Taproot upgrade was officially activated at the end of 2021, and the upgrade consists of three major Bitcoin Improvement Proposals (BIPs): Schnorr Signature (BIP 340), Taproot (BIP 341), and TapScript (BIP 342).
Among them, BIP 341 defines a new way to send bitcoin - Pay-to-Taproot (P2TR), which combines the functionality of Pay-to-Public-Key (P2PK) and Pay-to-Script-Hash (P2SH) scripts to provide users with great flexibility and privacy benefits.
P2TR is essentially a ScriptPubKey that locks Bitcoin onto a script that allows users to pay the Merkle root of the Schnorr public key or various other scripts. Ostensibly, a P2TR output locks Bitcoin to a Schnoorer public key, which we assume is Q. However, this public key Q is actually the sum of a public key P and a public key M, which is computed by the Merkle root of the other ScriptPubKeys lists.
The bitcoins in the P2TR output can be spent either by issuing the signature of the public key P, which is called the key path, or by satisfying one of the scripts contained in the Merkle tree, which is called the key path, and the latter being the script path. While there may be many ways to output P2TR, only the one that is used will be made public, which will keep it private for other unused alternatives.
In addition, due to the Schnorr key aggregation feature, the public key P itself can be an aggregate key, and the state of the public key P as an aggregate key or a single key is never revealed, because all P2TR outputs are similar to each other, which will break many chain analysis heuristics and enhance user privacy.
1. Other payment methods
In addition to Pay-to-Taproot (P2TR), there are four common payment methods in the Bitcoin network: Pay-to-Public-Key-Hash (P2PKH), Pay-to-Witness-Public-Key-Hash (P2WPKH), Pay-to-Script-Hash (P2SH), and Pay-to-Witness-Script-Hash ( P2WSH), each of these payment methods has different characteristics and application scenarios.
P2PKH
Pay-to-Public-Key-Hash (P2PKH) is a ScriptPubKey that locks Bitcoin on a hash of a public key (Bitcoin address). For example, Alice wants to send 1 BTC to Bob in a P2PKH transaction, Bob provides Alice with an address in his wallet, and Bob's address is included in the transaction. When Bob tries to spend the bitcoins he receives, he must sign the transaction with the private key that corresponds to the public key, which is hashed to match the hash provided in Alice's transaction.
P2WPKH
Pay-to-Witness-Public-Key-Hash (P2WPKH) is a ScriptPubKey that is used to lock bitcoins to a SegWit address. The P2WPKH transaction is similar to the P2PKH transaction in most ways, it still locks the Bitcoin to the hash of the public key, with the main difference being that P2WPKH uses SegWit. This means that all input ScriptSig (the script that unlocks Bitcoin) is removed from the transaction body and enters the witness section, and is called a script witness. This data is still recorded on the blockchain, but the fees generated for the data will be lower than regular data, making SegWit transactions cheaper than regular transactions.
P2SH
Pay-to-Script-Hash (P2SH) is a ScriptPubKey that is primarily used in multisig wallets to make output script logic and check for multisig before accepting transactions. For example, if Alice sends 1 BTC to Bob in a P2SH transaction, she will include the hash of the script needed to spend Bitcoin in the transaction. This script may require Bob's private key and/or the signature of many others. When Bob wants to spend the bitcoins he received from Alice, he reconstructs the hash of the script that Alice used to send the bitcoins and signs the transaction with whatever private key the script requires. P2SH is very flexible because it allows users to build arbitrary scripts. In addition, the sender of the transaction does not need to know what type of script they are sending to. In the example above, Bob can build the script he wants offline and only send Alice a hash of that script, keeping more privacy for Bob.
P2WSH
Pay-to-Witness-Script-Hash (P2WSH) is a transaction type that is similar to P2SH transactions in most ways, except that it uses SegWit. Like P2SH transactions, P2WSH transactions lock bitcoins to a hash of the script. In order to spend this bitcoin, the spender must present a script called RedeemScript and any required signatures. On a technical level, P2WSH actually describes the ScriptPubKey used to lock Bitcoin to the SegWit script hash.
2.P2TR advantages
By comparing the different types of signature sizes, it can be seen that using P2TR on a single signature is a bit larger than an equivalent P2WPKH, but a closer look reveals that there are many benefits to using P2TR for single-signature wallet users and the network as a whole:
P2TR costs cheaper
At the investment level, it costs about 15% less to spend a single-signature P2TR UTXO than to spend a P2WPKH UTXO. An overly simplistic analysis like the table above hides a detail that the spender can't choose the address they're asked to pay for, so if you stay on P2WPKH and everyone else upgrades to P2TR, the actual typical size of your 2-in-2-out transaction will be 232.5vbytes, while all P2TR transactions will still only be 211.5vbytes.
P2TR has better privacy
While early adopters lose some privacy when they switch to the new script format, users who switch to Taproot also get an immediate boost in privacy. Your transactions will be able to look no different from those working on new LN channels, more efficient DLCs, secure multi-signatures, various clever wallet backup and recovery schemes, or a hundred other groundbreaking developments. Single-signature with P2TR now also allows your wallet to upgrade to multi-signature, Tapscripts, LN support, or other features at a later date without compromising the privacy of your existing users. It doesn't matter if the old or new version of the software receives the UTXO – both UTXOs will look the same on-chain.
P2TR is more convenient for hardware signing devices
Since the rediscovery of the Fee Overpayment Attack, some hardware signing devices have refused to sign a transaction unless each UTXO spent in that transaction has metadata that contains a copy of a significant portion of the entire transaction that produced that UTXO. Taproot, on the other hand, eliminates the potential vulnerability of overpayment attacks, so it can significantly improve the performance of hardware signers.
P2TR has more predictability
ECDSA signatures for P2PKH and P2WPKH UTXOs can have different sizes, and since wallets need to choose the rate of the transaction before creating the signature, most wallets just assume the worst-case signature size, so they will pay slightly more when accepting smaller signatures. Whereas for P2TR, the size of the signature is known in advance, allowing the wallet to choose a precise rate.
P2TR helps complete nodes
The overall security of Bitcoin depends on the majority of Bitcoin users using their own nodes to verify every confirmed transaction, including the transactions created by your wallet. Taproot's schnorr signatures can be effectively used for batch verification, and the CPU cycles required for nodes to verify signatures are reduced by about 1/2 during the process of synchronous blocks. Even if you reject all of the above benefits, consider using Taproot to help run a full node.
3. Support P2TR
For wallets that already support receiving and spending v0 segwit P2WPKH output, upgrading to v1 segwit P2TR for single signing should be easy, here are the main steps:
Use the new BIP32 key to derive the path
It is highly recommended to use a new derivation path (e.g. defined by BIP86) for the P2TR public key, which can be attacked if you use the same key in both ECDSA and schnorr signatures.
Adjust your public key by hashing it
While a single signature is not technically required, especially if all of your keys are from a randomly selected BIP32 seed, BIP341 recommends submitting your keys to a non-consumable scripthash tree. It's as simple as using elliptic curve addition, adding your public key to the curve points of the hash of that key. The benefit of following this advice is that if you add support for scriptless multi-signature in the future, or add support for tr() descriptors, you will be able to use the same code.
Create your address and monitor it
Use bech32m to create your address. The payment will be sent to the scriptPubKey OP_1. You can use any method used to scan v0 SegWit addresses (e.g. P2WPKH) to scan transactions for payment scripts.
Create an expense transaction
All of Taproot's non-witness fields are the same as P2WPKH's, so you don't need to worry about changes to transaction serialization.
Create a signature message
It's a promise of data for spending transactions. Most of the data is the same as the data you signed for the P2WPKH exchange, but the order of the fields is changed and there are a few extra things that are signed. Achieving this is just a matter of serializing and hashing all sorts of data, so writing code should be easy.
The hash value of the signature information
There are many different ways to create Schnorr signatures. So the best approach at the moment is not to "roll out your own methods", but to use features from a highly vetted library that you trust. However, if you can't do that for some reason, BIP340 provides an algorithm that should be easy to implement if you already have the foundation for making ECDSA signatures. When you have your signature, put it in the entered witness data and send your payout transaction.
4. Summary
Overall, P2TR not only simplifies the transaction process and enhances user privacy, but also allows for flexible payment methods and more complex smart contract execution. Bitcoin's Layer2 solution, BEVM, takes full advantage of this by making Taproot one of the core architectures of its "Taproot Consensus" technology, bringing the Bitcoin network's privacy, scalability, and smart contract processing capabilities to new heights.
In BEVM, all transactions are in P2TR format, which means that every transaction benefits from lower fees, better privacy protection, and friendly support for hardware-signed devices. In addition, BEVM leverages P2TR's key path and script path features to ensure the privacy and security of transactions while improving the scalability of the network. Through these technologies, the BEVM project has successfully built a more reliable smart contract platform within the Bitcoin ecosystem, promoting further development.

2024-09-03 02:30:48

Understanding Taproot Transactions: Achieving More Complex Transactions with Fewer Bytes
https://m.primal.net/KbYc.jpg
To address efficiency, privacy, and flexibility issues within the Bitcoin network, the Bitcoin development community implemented the Taproot upgrade at the end of 2021. The core components of this upgrade include Schnorr signatures and MAST (Merkelized Abstract Syntax Tree).
Schnorr's key aggregation feature allows participants in a single multi-signature transaction to collaboratively combine their public keys and generate an aggregate signature that is valid for the sum of their public keys. This saves block space, enhances privacy, and enables faster transaction verification. MAST improves the privacy and efficiency of Bitcoin scripts by breaking down complex Bitcoin scripts into smaller sub-scripts and utilizing the Merkle tree structure.
To fully understand how Taproot operates, this article explains the Taproot transaction process from two main aspects: the creation of the Taproot public key and the spending patterns of Taproot.
I. Creating the Taproot Public Key
To create a Taproot public key, we first need to understand the process of generating an aggregated public key and aggregated signature. The most notable related research includes MuSig1 and MuSig2. Compared to MuSig2's two-round communication mechanism, MuSig1's major drawback is that it requires three rounds of communication to create a signature, each consisting of back-and-forth message exchanges. Since this article does not involve inter-network communication, we will focus on the basic generation process of aggregated public keys and signatures.
II. Aggregated Public Key
https://m.primal.net/KbYg.png
The generation process of the aggregated public key can be divided into three steps:
-Exchange public keys and perform an aggregation hash on all concatenated public keys to generate `c_all`.
-Concatenate `c_all` with each participant's public key and perform a hash to generate the factor `c_i`.
-Linearly combine the factors `c_i` to obtain the aggregated public key `P_agg`.
https://m.primal.net/KbYj.png
III. Aggregated Signature
https://m.primal.net/KbYm.png
The generation process of the aggregated signature requires three rounds of communication and can be divided into two main steps:
-Generate nonces and linearly aggregate them to form `R_agg`.
-Each participant uses their private key to generate a Schnorr signature, and these signatures are then aggregated to obtain the final aggregated signature `(R_agg, s1+s2+s3)`.
https://m.primal.net/KbYp.png
IV. Introducing MAST
https://m.primal.net/KbYr.png
As shown in the diagram, the Taproot public key primarily consists of two parts: the aggregated public key `P` and the public key `tG` formed by the MAST structure. Assuming `P` is the aggregated public key of Alice, Bob, and Charlie, and `script_A`, `script_B`, and `script_C` are the scripts related to Alice, Bob, and Charlie respectively, the Taproot public key creation process is as follows:
1. Alice, Bob, and Charlie each generate their own public and private keys.
https://m.primal.net/KbYt.png
2. The public keys are aggregated into `pubkey_agg`, and the private keys are adjusted for future signatures.
https://m.primal.net/KbYv.png
3. Create scripts `script_A`, `script_B`, and `script_C`.
https://m.primal.net/KbZA.png
4. Construct the MAST, and calculate the private key `taptweak` corresponding to the MAST structure. In the diagram, `TaggedHash` represents a tagged hash with a fixed length of 32 bytes, calculated as `TaggedHash(tag, x) = sha256(sha256(tag) + sha256(tag) + x)`. `ver` represents the Tapscript version number, currently set to `0xc0`, and `size` represents the byte size of the script. `A&B` represents the concatenation of `A` and `B` in dictionary order.
https://m.primal.net/KbZE.png
5. Combine `Q=P+tG` to form the Taproot public key and generate a `segwit_address` for the transaction.
https://m.primal.net/KbZF.png
6. Transfer 50 BTC to the Taproot address.
https://m.primal.net/KbZI.png
V. Taproot Spending
There are two payment methods for transferring 0.5 BTC from the Taproot address to Bob: one involves Alice, Bob, and Charlie all signing to form an aggregated signature, completing the transfer to Bob; the other involves using the script in the MAST structure to transfer to Bob.
Create the raw transaction, filling in the recipient address, transfer amount, and other data.
For the first method, Alice, Bob, and Charlie each generate nonces and aggregate them, then each uses their private keys to generate Schnorr signatures, and finally aggregate the signatures. Thus, the final witness script is a single signature with a fixed length of 64 bytes.
Test the legality of the transaction created by the first method and send the transaction.
For the second method, assume Alice completes the transfer to Bob through `script_A`. The witness script needs to include:
`[Stack element(s) satisfying TapScript_A]`
- `[TapScript_A]`
- `[Controlblock c]`, where `[Controlblock c]` represents the proof related to `TapScript_A`, with a length of `33+32n`. The first byte of the 33 bytes is calculated from the aggregated public key and the Taproot version number, and the remaining 32 bytes represent the x-coordinate of the aggregated public key. `32n` represents the proof of `TapScript_A`, and in this example, `n=2`, referring to `taggedhash_leafB` and `taggedhash_leafC`.
5. Test the legality of the transaction created by the second method and send the transaction.
VI. Summary
Overall, Taproot transactions focus on one type of output and two spending patterns. One type of output ensures that the public key in the locking script is consistent, whether for individual or multi-signature transactions, making it indistinguishable in form. The two spending patterns enable transaction participants to achieve more complex transactions and a wider variety of application scenarios with fewer bytes.
Recognizing the technical characteristics of the Taproot mechanism, the Bitcoin Layer 2 solution BEVM has adopted it as one of the core architectures of the "Taproot Consensus" technology. By combining Schnorr signatures and MAST, BEVM can provide a more efficient and flexible smart contract execution environment while ensuring security, pushing the entire Bitcoin ecosystem towards a more secure and efficient future.
#Bitcoin #BTCL2 #Taproot #BTC

2024-08-29 08:58:57

Why is BEVM Vigorously Developing On-Chain Hashrate Finance(HashFi)?
https://m.primal.net/KTMo.jpg
After receiving investment from Bitmain, the world's largest Bitcoin mining server manufacturer, we have re-evaluated BEVM's development strategy. Among numerous Bitcoin L2 solutions, BEVM needs to carve out a unique and effective path.
In June 2024, BEVM announced a $10 million Hashrate RWA Ecosystem Support Program, aiming to support 10-20 hashrate RWA startup teams. The goal is to migrate the $20 billion annual hashrate market on-chain, ultimately unlocking a nearly $100 billion on-chain hashrate finance market.
Within three months, the program has received over 30 applications, with nearly 10 hashrate RWA startup teams deploying on the BEVM chain. Notable projects include BitTera, Miner Club, and LRWA. BitTera launched its first batch of Bitcoin hashrate RWA in July, selling out within 36 hours, reflecting the market's recognition of hashrate RWA products alongside BitTera's excellent operational capabilities.
Moving forward, BEVM will continue to promote the HashFi ecosystem and adopt "On-Chain Hashrate Finance—HashFi" as its strategic development focus. To fully support this strategy, BEVM will use user-owned hashrate RWA assets as one of the most important credentials for future BEVM token and ecosystem project token airdrops.
Why is BEVM focusing on on-chain hashrate finance (HashFi) as its strategic development?
1. Validated Hashrate Market:
The hashrate market, or mining ecosystem, has been a validated crypto business sector for over a decade but has long been isolated from on-chain finance.
Users want to buy hashrate and earn real mining returns; miners have genuine and urgent borrowing needs. Whether it's electricity loans, hashrate loans, or BTC loans, the market has grown to over $10 billion. However, these needs have been inefficiently met off-chain without leveraging efficient on-chain financial tools to improve efficiency and scalability.
Connecting these traditional hashrate market demands through on-chain finance could unlock a nearly $100 billion on-chain HashFi market, which is one reason BEVM is focusing on this area.
2. Lack of Sustainable Business On-Chain Models:
The current crypto market, whether L1 or L2, largely lacks sustainable business models and effective user retention mechanisms. Many chains attract users with various incentives and on-chain activities before token issuance, but user activity drops sharply post-airdrop, as these chains fail to provide genuine, essential services and sustainable business models.
Migrating the hashrate market on-chain would bring real, effective business to the chain. On-chain asset yield protocols can offer miners more earning opportunities, and on-chain financial tools can efficiently meet miners' genuine borrowing and leverage needs.
https://m.primal.net/KTMr.jpg
With real business and real needs, more business models will naturally emerge on-chain, and the chain will no longer lack genuine users. This is the second reason BEVM is focusing on developing the HashFi ecosystem.
‍3. Unique Resource Advantage from Bitmain:
As the world's most influential Bitcoin mining institution, Bitmain not only leads in Bitcoin mining hardware but also has long-term plans and resource advantages in Bitcoin mining pools, hashrate markets, and HashFi markets.
BEVM, as Bitmain's only investment in the Bitcoin Layer2 space, can leverage these unique resources to migrate substantial off-chain hashrate market demands on-chain, developing a distinctive on-chain HashFi ecosystem.
Therefore, BEVM will not only support the hashrate RWA market but also venture into on-chain mining pool businesses and on-chain hashrate lending businesses.
How will BEVM support the development of the on-chain HashFi ecosystem from strategy to tactics?
1. BEVM will continue to advance the $10 million HashFi Ecosystem Support Program, aiming to support 10-20 on-chain HashFi startup teams.
2. BEVM will use on-chain hashrate RWA as one of the most important credentials for airdrops. The amount of hashrate RWA held will correlate with the airdrop size. Future BEVM and ecosystem project airdrops will also favor users holding hashrate RWA assets.
In summary, these are the reasons and specific strategies for BEVM's vigorous development of the on-chain HashFi ecosystem. Ultimately, BEVM aims to become a Bitcoin Layer2 ecosystem with a real business model and long-term user retention, characterized by HashFi.
Let's build and look forward to this together!

2024-08-29 06:23:45

Detailed Explanation of Taproot Optimization: Reducing Transaction Fees with Huffman Tree.
https://m.primal.net/KTBi.jpg
In recent years, the Bitcoin ecosystem has developed rapidly but still faces many technical challenges and bottlenecks. As the number of users and transaction volumes increase, issues related to the efficiency, privacy, and flexibility of the Bitcoin network have become more prominent. To address these issues, the Bitcoin community introduced Bitcoin Improvement Proposals (BIPs) to add new features and improvements to the Bitcoin network.
I. Taproot Technology and Its Principles
At the end of 2021, Bitcoin underwent the Taproot upgrade, aiming to significantly enhance Bitcoin's performance and user experience. The Taproot upgrade is a collection of three BIPs, including Schnorr Signatures (BIP 340), Taproot (BIP 341), and TapScript (BIP 342), collectively known as BIP Taproot.
-Schnorr Signatures (BIP 340): The key aggregation feature of Schnorr allows participants in a single multi-signature transaction to collaboratively combine their public keys and generate an aggregate signature valid for their combined public key. This saves block space, enhances privacy, and enables faster transaction verification.
-Taproot (BIP 341): Defines Pay-to-Taproot (P2TR), a new way of sending Bitcoin. P2TR combines the functionalities of Pay-to-Public-Key (P2PK) and Pay-to-Script-Hash (P2SH) scripts, offering users great flexibility and privacy advantages.
-TapScript (BIP 342): Updates the scripting language used to write BTC transaction parameters to accommodate users using Schnorr and Taproot technologies.
https://m.primal.net/KTBt.png
The principle of Taproot is to define an output and two spending paths. As illustrated above, with two participants, Alice and Bob, the Taproot operation process is as follows:
-Aggregate Alice and Bob's public keys: C = P_A + P_B.
-Add MerkleRoot, and aggregate the public key as: P = C + H(C||MerkleRoot)G, where H(C||MerkleRoot) represents the combined hash of C and MerkleRoot.
-Fill the aggregated public key P into the locking script, similar to Segwit format: [ver] [P]. Here, ver represents the version number, with ver=1 in Taproot.
-There are two spending paths, one of which can be chosen:
---Signature Mode: Alice and Bob both sign to generate an aggregate signature, which is filled into the witness script. After verifying the signature against the aggregate public key P, the spending can be completed.
---Script Mode: If one of Alice or Bob refuses to sign, the script mode can be used. If Alice wants to complete the spending, the witness script needs to include: execution data D that complies with Script 1, Script 1, C, and Hash 2. To verify the signature, first use Script 1 and Hash 2 to compute MerkleRoot, then verify if P == C + H(C||MerkleRoot)G holds, and finally construct the complete script D||Script 1 and execute it, verifying if the result is true. Once the above verification passes, the spending is completed.
When spending in signature mode, multiple participants and single participants appear indistinguishable on the blockchain, making many blockchain analyses ineffective and preserving privacy for all Taproot users. The script spending mode of Taproot provides a solution for cases where some signers cannot or refuse to sign, allowing participants to complete transactions through predefined conditions and script paths. This way, even if not all signers agree to the transaction, the remaining participants can still spend according to preset conditions.
II. Huffman Tree
The Huffman Tree, proposed by David Huffman in 1952, is an optimal binary tree used for data compression. Its main application is in the field of data compression, such as file compression and image compression. It achieves data compression by assigning shorter codes to frequently occurring characters and longer codes to less frequent characters.
https://m.primal.net/KTCG.jpg
The Huffman Tree is the tree with the shortest weighted path length, where nodes with larger weights are closer to the root, and nodes with smaller weights are farther from the root. Its construction process uses a greedy approach, selecting the two nodes with the smallest weights each time to combine into a new node, adding it to the original set, and repeating the process until completion. As illustrated above, with a weight set of (1, 2, 3, 4, 5), the Huffman Tree construction process is as follows:
-Select the nodes with the smallest weights, 1 and 2, and combine them into a node with a weight of 3, resulting in a set of (3, 3, 4, 5).
-Select the nodes with the smallest weights, 3 and 3, and combine them into a node with a weight of 6, resulting in a set of (4, 5, 6).
-Select the nodes with the smallest weights, 4 and 5, and combine them into a node with a weight of 9, resulting in a set of (6, 9).
-Select the nodes with the smallest weights, 6 and 9, and combine them into a node with a weight of 15, resulting in a set of (15), ending the construction process.
III. Application of Huffman Tree in Taproot
Compared to ECDSA (Elliptic Curve Digital Signature Algorithm), a major advantage of Taproot is that Schnorr aggregate signatures can compress multiple signature data into a single aggregate signature. After using aggregate signature technology, the byte size of the transaction script is significantly reduced, effectively lowering the transaction fees.
In signature mode, as the number of participants increases, the size of ECDSA transaction scripts grows linearly, while the size of Taproot transaction scripts remains unchanged. In script mode, as the number of scripts increases, the size of ECDSA transaction scripts grows linearly, while the size of Taproot transaction scripts grows logarithmically.
When spending in script mode, using the tree structure of MAST, the size of Taproot transaction scripts grows logarithmically with the number of scripts. However, by using the Huffman Tree, we can improve the construction process of MAST, helping to further reduce the byte size of witness scripts in script spending mode, ultimately achieving lower transaction fees.
https://m.primal.net/KTCk.jpg
As mentioned earlier, when spending in script mode with Taproot, proof of the script in MAST is required. As illustrated above, when we want to spend using script_A, the witness script needs to provide:
-Execution data D that complies with script_A
-script_A
-P
-TaggedHash(B), TaggedHash(C) TaggedHash represents a tagged hash, with a fixed length of 32 bytes. The purpose of using tagged hash is to reduce hash collisions.
Ignoring the byte size of the first two items, it can be seen that the byte size of the last item can be represented as 32*(d-1), where d=3 represents the height of script_A in MAST. In other words, the byte size of the last item is linearly related to the height of the script in MAST. Therefore, for scripts script_A, script_B, and script_C, we can assign weights based on their usage frequency and construct a Huffman Tree. This can place frequently used scripts at lower heights, reducing the byte size of witness scripts and ultimately lowering transaction fees.
In summary, transaction fees are closely related to the byte size of transaction scripts.
The introduction of Taproot marks an important step forward for the Bitcoin network in terms of efficiency, privacy, and flexibility. By adopting new technologies such as Schnorr signatures, MAST, and TapScript, Taproot not only significantly reduces the byte size of transaction scripts and lowers transaction fees but also enhances user privacy. The strategy of using Huffman Tree to optimize MAST construction further reduces the byte size of witness scripts in script spending mode, providing Bitcoin users with a more efficient transaction experience.
Bitcoin Layer 2 solution BEVM uses Taproot as one of the core architectures of its "Taproot Consensus" technology, bringing explosive growth to the Bitcoin ecosystem. As these improvements gradually become widespread, the Bitcoin network will be able to handle larger-scale users and transaction volumes, providing global users with more secure and convenient encryption services.
#Bitcoin #BitcoinLayer2 #BTCL2 #BTC #Taproot

2024-08-19 06:57:59

An easy-to-understand interpretation of BEVM technical solution!
https://m.primal.net/KEHN.png
BEVM is a Bitcoin L2 solution entirely built on Bitcoin's native technology.
Following the Bitcoin Taproot upgrade in 2021, the BEVM team developed a fully decentralized Bitcoin layer2 technology framework based on Schnorr signatures + MAST(Merkle Abstract Syntax Tree) and other Bitcoin native technologies. The BEVM Canary network has been operational for 8 months (launched in July 2023), with over 100,000 on-chain users, 6 million on-chain TXs and more than 30 projects in its ecosystem, covering 15 different tracks including $BTC stablecoins, DEX, Lending, etc. It is one of the few Bitcoin L2 solutions that has launched the Canary network.
Leveraging years of exploration and accumulation in the Bitcoin L2 space, the BEVM team was among the first to identify the core proposition of Bitcoin layer2: how to achieve decentralized cross-chain mechanism for $BTC. Based on Bitcoin's native technology, the BEVM team proposed a fully decentralized $BTC cross-chain solution, providing a solid technical foundation for the implementation of Bitcoin layer2.
[I. History of BEVM Team in Bitcoin L2]
The BEVM team has six years of experience in developing and operating Bitcoin L2 solutions. In 2018, the core team of BEVM introduced ChainX, employing Bitcoin's 15-signature multisig and Bitcoin light nodes to achieve $BTC cross-chain bridge, ultimately facilitating the cross-chain of over 100,000 $BTC.
However, the 15-signature multisig solution was still relatively centralized and did not address the complete truthfulness issue of $BTC cross-chain, until the Bitcoin Taproot upgrade at the end of 2021.
The 2021 Taproot upgrade brought two core BIPs to Bitcoin: Schnorr signatures and MAST, offering a new vision for a fully decentralized Bitcoin L2 solution to the BEVM team.
Schnorr signatures, an aggregate signature technique, offer higher efficiency, smaller storage requirements, and better privacy than elliptic curve signatures. While Bitcoin's maximum multisig address count based on elliptic curve signatures is 15, Schnorr signatures allow for expanding this count to 1,000. Managing $BTC with 1,000 multisig addresses on the blockchain consumes only a single Gas fee while ensuring the privacy of all multisig addresses.
https://m.primal.net/KEHX.png
(Explanation of the Schnorr Aggregate Signature Scheme)
When Satoshi Nakamoto created Bitcoin in 2008, Schnorr signatures were not yet open-sourced (they were open-sourced in 2009), leading him to opt for elliptic curve signatures. After 12 years of development and validation, Schnorr signatures were proven more suitable for Bitcoin, leading to their formal introduction into Bitcoin by the Bitcoin Core team, opening a new chapter for Bitcoin's scalability.
Schnorr signatures could expand Bitcoin's multisig address count from 15 to 1,000, enabling more decentralized management of Bitcoin.
MAST(Merkle Abstract Syntax Tree), introduced in the Bitcoin Taproot upgrade, can be understood as an equivalent smart contract instruction set. With MAST, the 1,000 multisig addresses powered by Schnorr signatures do not need to rely on individuals for signing but can be driven by MAST contracts. Thus, the introduction of MAST contracts eliminated the need for multiple signers, driving the smart and code-based management of multisig addresses without human intervention, moving closer to complete trustlessness for $BTC cross-chain and management.
https://m.primal.net/KEHZ.png
(Operating Logic of MAST Contracts)
While MAST + Schnorr signatures achieved the decentralization of the $BTC multisig address count and the codification and smart management of multi-signature, the question remained: who would drive the MAST? The answer cannot involve humans. Only through network consensus can MAST truly achieve trustlessness, enabling network consensus to manage and spend Bitcoin in a decentralized approach.
Therefore, the BEVM team innovatively integrated Bitcoin light nodes into the L2 as verification nodes, merging Bitcoin L1 Taproot multisig addresses with the L2 Bitcoin light nodes. These Bitcoin light nodes serve as both the block-producing nodes of the BEVM network and the custodians on Bitcoin Mainnet. For example, when the network consensually decides to transfer 10 $BTC from a BEVM address back to the Bitcoin mainnet, the L1 Taproot multisig addresses will automatically execute a 10 $BTC transaction through MAST. Note that this $BTC cross-chain and management process involves no human participation and is entirely driven by network consensus, achieving true trustlessness.
In summary, the core of BEVM's Bitcoin L2 solution is based on Bitcoin's Schnorr signatures to achieve the decentralization of the number of multisig addresses (expandable to 1,000 multisig addresses); based on Bitcoin's MAST to realize the codification and smart management of multisignature (eliminating human involvement); and based on the Bitcoin light node network to facilitate communication between Bitcoin Mainnet and L2, ultimately relying on network consensus to drive Bitcoin's multisig and management, achieving a truly decentralized Bitcoin L2 solution.
It's worth mentioning that since the block-producing nodes in the BEVM network are all Bitcoin light nodes, if Bitcoin ceases to exist, so will the BEVM network. The BEVM network cannot exist independently from the Bitcoin network, making BEVM a true Bitcoin L2 solution, not a sidechain as misunderstood by some in the market.
[II. Why is achieving decentralized $BTC cross-chain so crucial for Bitcoin L2?]
As is well known, Bitcoin's highly simplistic UTXO design and limited block space cannot support smart contracts or complex scenario expansion. To achieve true scalability, $BTC must leap to a L2 network to handle complex scenarios. Therefore, decentralizing the $BTC Bridge to L2 is the first step all Bitcoin L2s must take. If decentralized $BTC cross-chain cannot be achieved, such so-called Bitcoin L2 solutions are built on an untrustworthy foundation, with their asset security and future development prospects naturally questionable.
However, most current so-called Bitcoin L2 solutions completely avoid discussing how to address the fundamental issue of $BTC cross-chain, instead lightly emphasizing the L2 technical jargon, such as ZK-rollup or OP-rollup. First and foremost, whether ZK-rollup or OP-rollup, Bitcoin nodes will not verify these data, rendering them meaningless. Even if these could make the L2 ledger somewhat trustworthy, the issues of how to manage and secure user assets in a decentralized $BTC cross-chain remain unavoidable.
BEVM, built on three core $BTC native technologies: Schnorr signatures, MAST contracts, and the Bitcoin light node network, perfectly solves the problem of secure decentralized $BTC cross-chain, breaking through the core proposition of Bitcoin L2.
To better build the Bitcoin ecosystem and robustly expand the Bitcoin L2 track, BEVM will fully open-source its Bitcoin L2 solution. After the mainnet launch, BEVM will introduce BEVM-Stack, i.e., a modular Bitcoin L2 feature, allowing anyone to build their own Bitcoin L2 with just one click based on BEVM-Stack. BEVM has already constructed a fully EVM-compatible Bitcoin L2 modular technology stack.
In the future, as the ecosystem develops, BEVM will also build technology stacks compatible with the StarkNet network's Cairo language, Solana's Rust language, and the MOVE language, aiming to bring $BTC into any chain through BEVM. This allows any blockchain innovation technology to be utilized by $BTC, maximizing both the value of $BTC and the benefits of blockchain technology, thereby establishing a BTC-native superchain network with BEVM as the technology stack.

2024-08-19 06:47:18

Introducing the First Decentralized Indexer Innovation on the BEVM Bridge!
Ensuring the security and traceability of innovative Bitcoin asset standards like #BRC20, #Ordinals, and #Runes in transactions is crucial to the community.
Learn how BEVM makes it happen.🔥🧵
https://m.primal.net/KEGy.jpg
1/ While BEVM SPV can obtain any #Bitcoin network transaction, it can't determine if it corresponds to #Runes/#Ordinals asset transactions or identify their type, quantity, or recipient due to their unique nature.
An external indexer is required to parse this information.
2/ Accurate recognition of #Runes/#Ordinals transaction information is crucial for the indexer.
Unlike Bitcoin light clients, mainstream indexers like Unisat, OKLINK, BINANCE, and ORDISCAN are not protected by the Bitcoin network, posing centralized risks.
3/To this end, BEVM has proposed its decentralized indexer solution.
1️⃣Decentralized Indexer Nodes: Each validator must introduce the Runes/Ordinals indexer based on their own Bitcoin SPV. POS-based validator selection resolves single points of failure and centralization issues in existing indexers.
2️⃣Open-Source Indexer Cross-Validation: BEVM uses open-source indexers for cross-validation. Validators run this process on BEVM nodes, significantly reducing costs.
https://m.primal.net/KEHE.jpg
4/ We are integrating this first-ever decentralized indexer to Taproot Consensus to launch the decentralized #BRC20/#Ordinals/#Runes bridge.
Check more details here⤵️https://bevm-blog.webflow.io/post/why-is-a-decentralized-indexer-important-for-runes-ordinals-assets

2024-08-19 02:54:29

🟡The First Sats Network is Live on BEVM Stack!🟡
Sats Chain, the groundbreaking #Bitcoin L2 utilizes $SATS as gas fees and governance, while also is our attempt to merge:
"ℂ𝕠𝕞𝕞𝕦𝕟𝕚𝕥𝕪-𝔻𝕣𝕚𝕧𝕖𝕟 + 𝕋𝕖𝕔𝕙𝕟𝕠𝕝𝕠𝕘𝕪 + 𝕄𝕒𝕣𝕜𝕖𝕥𝕚𝕟𝕘"
Ready to explore?🧵https://m.primal.net/KDwz.jpg
1/ Sats Chain is the first pre-development platform offering a secure sandbox for developers to test with $BTC and $sats-based applications.
It uses genuine $sats for transaction fees and governance.
2/ Sats Chain integrates BEVM's key features like Taproot Consensus and Byzantine PoS for system state consistency.
The difference? $sats is the sole governance token, enabling community members to stake it and elect validators and custodians.
3/ As an independent L2 for the #SATS community, it's BEVM's latest effort to merge community, technology, and market.
1️⃣Unifying the Community: Since May 2023, BEVM's free inscription tool, BITBOX, has helped inscribe 20% of $sats tokens, showing strong cohesion within the #Ordinals and #Bitcoin community.
2️⃣Testing BEVM-Stack: Our core BEVM-Stack model has attracted interest from over 40 projects. Impressed by the $sats community's enthusiasm, we decided to assist in developing a Bitcoin L2 and test BEVM-Stack with them.
3️⃣Testing BEVM's Decentralized Indexer: We launched it as a pre-dev environment offering early BEVM features, including the first decentralized indexer, to test its decentralization and security.
Key official upgrades of the BEVM mainnet will also be tested first on it.
https://m.primal.net/KDxJ.jpg
4/Soon, BEVM will collaborate with the #SATS community to launch more exciting activities.🎮
Of course, BEVM will transfer the responsibilities to the community, achieving a truly community-governed open network.
Read the article here: https://bevm-blog.webflow.io/post/announcing-sats-chain-the-first-community-driven-decentralized-bitcoin-l2-based-on-bevm-stack

2024-08-15 07:34:39

Introducing BEVM Stack: One-Click Bitcoin Layer2 Solutions
1. Introduction
BevmStack is a modular, open-source blockchain technology stack designed to seamlessly integrate Bitcoin assets with Ethereum Virtual Machine (EVM) compatible smart contract functionality. Drawing inspiration from the OP Stack design philosophy, it provides a comprehensive set of tools and components for building, deploying, and operating scalable blockchain networks that are tightly integrated with the Bitcoin ecosystem.
1.1 Key Features
🔗 Seamless Bitcoin and EVM integration
🚀 High-throughput and low-latency transaction processing
💡 Multi-asset fuel mechanism
🌉 Advanced cross-chain asset management
🛡️ Multi-layered security architecture
🧰 Rich developer tools and SDK support
2. System Architecture
The following diagram illustrates the various components of the BevmStack ecosystem and their interrelationships:
https://m.primal.net/KACw.png
The architecture diagram clearly shows the multi-layered structure of BevmStack, including:
-Bitcoin Ecosystem Layer: Encompasses the Bitcoin network, BRC20 tokens, and Runes.
-BevmStack Core Layer:
· Consensus Layer: Integrates Bitcoin SPV, Taproot consensus, and PoS consensus.
· Execution Layer: Contains EVM and WebAssembly virtual machines.
· Smart Contract Layer: Composed of BevmStack contracts and Pallets.
-Bridge and Interoperability Layer: Enables cross-chain asset transfer and operations.‍
-User Interface Layer: Includes BevmStack wallet and block explorer.‍
-Developer Tools Layer: Provides SDK, CLI tools, and testnet.
3. Core Technical Components
3.1 BevmStack Chain
The BevmStack Chain is the foundation of the entire ecosystem, supporting multiple Bitcoin assets as transaction fuel and providing an EVM-compatible smart contract environment.
3.1.1 Hybrid Consensus Mechanism
BevmStack employs an innovative hybrid consensus mechanism, combining the following technologies:
https://m.primal.net/KACz.png
-Bitcoin SPV (Simplified Payment Verification): Implements lightweight verification with the Bitcoin main chain, ensuring the security of cross-chain operations.
-Taproot Consensus: Enhances transaction privacy and scalability, improving overall network performance.
-PoS (Proof of Stake) Consensus: Ensures network efficiency and sustainability while reducing energy consumption.
This hybrid consensus mechanism not only guarantees network security and efficiency but also achieves tight integration with the Bitcoin network.
3.1.2 Dual Virtual Machine Architecture
The BevmStack Chain supports a dual virtual machine architecture, which is another key aspect of its technological innovation:
https://m.primal.net/KADD.png
-WebAssembly (WASM) Virtual Machine: Executes system-level contracts, managing core blockchain functionalities. WASM's high performance and cross-platform characteristics make it an ideal environment for executing system-level contracts.
-EVM: Provides an Ethereum-compatible smart contract execution environment, supporting a rich DApp ecosystem.
This dual virtual machine architecture allows BevmStack to achieve both system-level high performance and user-level wide compatibility.
3.2 BevmStack Bridge
The BevmStack Bridge is a decentralized cross-chain solution designed to enable seamless asset transfer and interoperability between the Bitcoin network and the BevmStack chain. It employs advanced technologies such as Taproot, Bitcoin SPV (Simplified Payment Verification), and BFT (Byzantine Fault Tolerance) consensus to achieve fully decentralized cross-chain asset transfers. The following sequence diagram illustrates its workflow:
https://m.primal.net/KADG.png
This process ensures secure and efficient asset transfer between different chains, providing users with a seamless cross-chain experience.
3.3 Smart Contract Ecosystem
The BevmStack smart contract ecosystem consists of two main parts:
-BevmStack Contracts: EVM-compatible smart contracts for managing cross-chain assets and developing DApps.
-BevmStack Pallets: WebAssembly-based smart contracts for managing core blockchain system functions.
https://m.primal.net/KADJ.png
This dual-layer smart contract structure allows BevmStack to provide both high-performance system management and flexible application development environments.
4. Key Technological Innovations
4.1 Multi-Asset Fuel Mechanism
BevmStack supports multiple Bitcoin assets as transaction fuel, significantly increasing the utility of Bitcoin assets:
https://m.primal.net/KADK.png
This mechanism not only enhances network flexibility but also provides new application scenarios for various assets in the Bitcoin ecosystem.
4.2 Cross-Chain Asset Management
Through innovative decentralized cross-chain bridge technology, BevmStack achieves secure and transparent conversion of Bitcoin assets to EVM-compatible environments:
https://m.primal.net/KADL.png
This decentralized cross-chain asset management mechanism not only enhances the liquidity and use cases of Bitcoin assets but also ensures the security and transparency of the cross-chain process. By introducing a decentralized indexing mechanism to parse and process BRC20/Runes transactions, it ensures that complex asset types can also be transferred across chains in a decentralized manner, increasing the flexibility and applicability of the entire system.
4.3 Security Considerations
BevmStack adopts a multi-layered security architecture to ensure network security:
https://m.primal.net/KADN.png
This multi-layered security architecture ensures that the network is adequately protected at all levels, from the underlying protocol to application-layer contracts.
5. Developer Tools and Ecosystem
To support an active developer community, BevmStack provides a rich set of development tools:
-Multi-language SDK support
-Command-line interface (CLI) tools
-Smart contract development frameworks
-Testnet and faucet services
-These tools significantly lower the entry barrier for developers, promoting the rapid development of the BevmStack ecosystem.
6. Conclusion
BevmStack represents a significant advancement in blockchain technology, innovatively combining Bitcoin's security with EVM's flexibility. Its unique architectural design, multi-asset support, and cross-chain capabilities open up new possibilities for blockchain technology. As the technology matures and the ecosystem expands, BevmStack is poised to become a key force in driving blockchain technology progress and application deployment.
By integrating Bitcoin's network effects with the flexibility of smart contracts, BevmStack provides a powerful infrastructure for decentralized finance (DeFi), non-fungible tokens (NFTs), and other innovative applications. As more developers and enterprises join the BevmStack ecosystem, we can reasonably expect to see the emergence of more groundbreaking blockchain applications and solutions.

2024-08-13 06:40:00

It's not in the true spirit of crypto at all.🙅
BEVM is committed to changing that even if the Layer 2s shut down, users can still reclaim their BTC through the timelock mechanism of state channels, ensuring complete security.
How?
"Lightning Network + Taproot Consensus = Decentralized Bitcoin Scaling Solution"
The Lightning Network gives users full control over their BTC, while Taproot Consensus manages BTC through a consensus mechanism instead of human intervention.✋
Stay tuned for more, BEVM is making a difference!⚔️
#Bitcoin
https://image.nostr.build/thumb/9768dda5dfbb6c6979dd007af564ae202372b9b5100090a968dfafc607ebbf4f.jpg