Rootstock | Research & Innovation Forum - Latest posts https://research.rsk.dev Latest posts RSKIP-545: Account Abstraction (EIP-7702) This is a proposal to implement EIP-7702 for account abstraction in Rootstock. This can lead to usability improvements. As with the original EIP-7702, this type of account abstraction can work with pre-existing infrastructure for smart wallet contracts, RIF-Relay, or ERC-4337 based services.

]]> https://research.rsk.dev/t/rskip-545-account-abstraction-eip-7702/501#post_1 Wed, 07 Jan 2026 19:56:52 +0000 research.rsk.dev-post-897 RSKIP-544: Reject code starting with `0xEF` (EIP-3541) This is a proposal to implement EIP-3541 which prevents the deployment of new contracts with bytecode starting with 0xEF. This is a per-requisite for account abstraction (EIP-7702)

init eip3541 by smishraIOV · Pull Request #544 · rsksmart/RSKIPs · GitHub

]]> https://research.rsk.dev/t/rskip-544-reject-code-starting-with-0xef-eip-3541/500#post_1 Wed, 07 Jan 2026 19:52:57 +0000 research.rsk.dev-post-896 RSKIP-543: Typed Transaction Envelope (EIP-2718) This is a proposal to implement EIP-2718 style typed transaction envelope in Rootstock. This will improve Rootstock’s compatibility with EVM chains ecosystem and make it easier to introduce other changes such as Account Abstraction

]]> https://research.rsk.dev/t/rskip-543-typed-transaction-envelope-eip-2718/499#post_1 Wed, 07 Jan 2026 19:47:55 +0000 research.rsk.dev-post-895 RSKIP-531: Mitigation of Fee-Withholding Incentive in REMASC Hello to the Rootstock community!

We’ve been researching a vulnerability in Rootstock’s REMASC reward system that could degrade network performance. We propose the RSKIP-531 as a possible solution.

The Problem: Fee-Withholding Strategies

REMASC’s delayed reward mechanism creates an unintended incentive for strategic miners to withhold transaction fees. Here’s what happens:

  • Strategic Behavior: Miners exclude transactions with fees from blocks they mine but with no rewards to them, delaying the fees to future blocks where they can capture part of the reward

  • Perverse Incentives: Higher fees actually make transactions slower, not faster, as miners have more incentive to delay them

  • No Penalization: Excluded transactions simply roll over with no cost to the withholding miner

The Impact:

  • Reduces network efficiency and user experience

  • Creates unfair advantages for strategic miners

  • Undermines the reliability of fee-based transaction prioritization

Proposed Solution: Immediate Partial Fee Distribution

We are proposing a modification to REMASC that distributes a small fraction (e.g., 3%) of transaction fees immediately to the block producer, while preserving the remaining 97% for the delayed reward system.

This solution:

  • Eliminates the incentive to withhold fees

  • Maintains REMASC’s security benefits

  • Improves network performance and user experience

  • Creates alignment between miner incentives and network health

Important Note: Although this strategy introduces a clear theoretical vulnerability in REMASC’s implementation, it is not currently observed in practice. Implementing it requires changes to mining software, coordination with mempool management, and tracking of matured block eligibility — all of which add engineering complexity. Given the current fee levels, the expected benefit may not justify the effort. However, if network usage and fees increase in the future, the strategy may become more profitable and more likely to be exploited.

Proposed RSKIP: RSKIP: Fee withholding mitigation by patogallaiovlabs · Pull Request #531 · rsksmart/RSKIPs · GitHub

]]> https://research.rsk.dev/t/rskip-531-mitigation-of-fee-withholding-incentive-in-remasc/498#post_1 Tue, 02 Sep 2025 15:14:47 +0000 research.rsk.dev-post-894 RSKIP-305 Peg-out efficiency improvement (Segwit) Thanks for sharing, @mirisarri!

]]> https://research.rsk.dev/t/rskip-305-peg-out-efficiency-improvement-segwit/368#post_5 Fri, 08 Aug 2025 13:07:05 +0000 research.rsk.dev-post-893 RSKIP-518: Network Upgrade Reed Thank you, @GoldenGatsby. We will for sure bring this topic again to the next Devs Calls. In the meantime, you can check BitVMX Bridge | Rootstock (RSK)

]]> https://research.rsk.dev/t/rskip-518-network-upgrade-reed/495#post_3 Fri, 08 Aug 2025 13:06:05 +0000 research.rsk.dev-post-892 RSKIP-305 Peg-out efficiency improvement (Segwit) Wow, this are great news! Achieving a 62 % improvement over the 66 % projection, is an outstanding result. Huge kudos to everyone who made it happen!

]]> https://research.rsk.dev/t/rskip-305-peg-out-efficiency-improvement-segwit/368#post_4 Thu, 07 Aug 2025 19:46:26 +0000 research.rsk.dev-post-891 RSKIP-305 Peg-out efficiency improvement (Segwit) I would also like to share the result of some tests executed with the code shared above.

We can see that with this new proposal, even after increasing the amount of members in the PowPeg to 20, peg-out transactions are still at least 40% cheaper.

]]> https://research.rsk.dev/t/rskip-305-peg-out-efficiency-improvement-segwit/368#post_3 Thu, 07 Aug 2025 19:25:47 +0000 research.rsk.dev-post-890 RSKIP-305 Peg-out efficiency improvement (Segwit) An implementation of this RSKIP has been completed and proposed to be included in the upcoming Reed network upgrade of rskj.

Code changes are open for review

]]> https://research.rsk.dev/t/rskip-305-peg-out-efficiency-improvement-segwit/368#post_2 Thu, 07 Aug 2025 19:25:01 +0000 research.rsk.dev-post-889 RSKIP-518: Network Upgrade Reed Great community call running through Reed Upgrade today! Sharing the link here for anyone who missed it https://www.youtube.com/live/BcuQ554gKdE?feature=shared

Lots of excitement about parallel transaction execution as well as the potential opportunity to expand the signatories on the PoWPeg.

When will we hear more about potentially combining the power of PowPeg with UNION? Sounded like a brilliant idea.

]]> https://research.rsk.dev/t/rskip-518-network-upgrade-reed/495#post_2 Thu, 07 Aug 2025 17:00:36 +0000 research.rsk.dev-post-888 Post quantum and rootstock Hi, I want to know how is Rootstock to handle the post quantum migration in bitcoin. I know this is not even yet developed and there are some options. But still I would like to know how the sidechain will handle it

]]> https://research.rsk.dev/t/post-quantum-and-rootstock/497#post_1 Thu, 24 Jul 2025 14:33:45 +0000 research.rsk.dev-post-887 RSKIP-518: Network Upgrade Reed Hello to the Rootstock community! :wave:

A network upgrade proposal has been recently published and is open for discussion.

This proposal primarily focuses on improvements to the PowPeg, aiming to enable more pegnatories to participate and to significantly reduce the cost of pegging out.

Additionally, several Testnet-only RSKIPs are being proposed as part of an incremental rollout strategy that enables validation in a less critical environment before Mainnet deployment. Some of these RSKIPs are related to the Union Bridge initiative—which is still pending community discussion—and aim to establish a more trust-minimized bridge leveraging BitVMX technologies.

Here are the key proposed improvements slated for inclusion in Reed:

  1. RSKIP-305: Peg-out efficiency improvement (Segwit)
  2. RSKIP-144: Parallel Transaction Execution for the Unitrie (Testnet-only)
  3. RSKIP-502: Union Bridge Integration: New Methods Added to PowPeg Bridge Contract (Testnet-only)
  4. RSKIP-516: Precompiled contracts for +/* on Secp256k1 (Testnet-only)

This proposal represents an initial step, and we warmly invite the community to participate in open discussions, share insights, and suggest further improvements. Your feedback is essential to shaping the future of Rootstock.

We also plan to host a community call in July 2025 to explore these proposed changes in more depth.

Thank you for your continued support and engagement!

]]> https://research.rsk.dev/t/rskip-518-network-upgrade-reed/495#post_1 Fri, 20 Jun 2025 15:37:55 +0000 research.rsk.dev-post-885 RSKIP517 – Block time-centric difficulty adjustment with uncle threshold In terms of risks, the most immediate consideration is coordination with existing protocols. Many DeFi applications, bridges, and services rely on a fixed number of confirmations, assuming ~30s block times. With this change, the time-per-confirmation drops, so protocols may need to revisit their assumptions about finality and security thresholds. Good communication will be key here.

On the implementation side, we also need to be careful about classic edge cases in difficulty adjustment logic. For example, the historical off-by-one bug in Bitcoin’s difficulty adjustment mechanism (see Bitcoin StackExchange) is a good reminder to carefully validate transition conditions and boundary cases during testing.

Importantly, this RSKIP is just the first step. Our plan is to monitor its impact on uncle rates and network stability. If the results are positive, we intend to propose further reductions in the block time target.

]]> https://research.rsk.dev/t/rskip517-block-time-centric-difficulty-adjustment-with-uncle-threshold/494#post_3 Wed, 18 Jun 2025 20:23:01 +0000 research.rsk.dev-post-884 RSKIP517 – Block time-centric difficulty adjustment with uncle threshold Seems like a great proposal. Way faster than Bitcoin L1, on par with Cardano and setting the stage for future improvements in the future. Any risks with implementing?

]]> https://research.rsk.dev/t/rskip517-block-time-centric-difficulty-adjustment-with-uncle-threshold/494#post_2 Wed, 18 Jun 2025 16:34:19 +0000 research.rsk.dev-post-883 RSKIP-491 - Reduce target difficulty to lower average block time to 10s (DRAFT) Closing this thread in favor of the new proposal: RSKIP-517

]]> https://research.rsk.dev/t/rskip-491-reduce-target-difficulty-to-lower-average-block-time-to-10s-draft/486#post_9 Tue, 17 Jun 2025 18:25:39 +0000 research.rsk.dev-post-882 RSKIP517 – Block time-centric difficulty adjustment with uncle threshold This thread introduces RSKIP517, a proposal to revise Rootstock’s difficulty adjustment mechanism to enable safer reductions in block time targets.

Motivation

The current difficulty algorithm was designed to maintain safe operation with a fixed block time and uncle production level. It achieves that goal under normal conditions, but exhibits two limitations when used to progressively shorten block intervals:

  1. Uncle rate conflation – The current design treats both main chain blocks and uncles as indicators of block frequency. This creates a feedback loop: reduced difficulty leads to higher uncle rates, which are misinterpreted as excess block production, triggering premature difficulty increases.
  2. Per-block sensitivity – Difficulty is adjusted based only on the latest block. Because block times follow an exponential distribution, this approach introduces persistent noise and a statistical bias that drifts the system away from the target.

These two effects make it difficult to lower block times without triggering instability.

Proposal

RSKIP517 addresses these issues by introducing a window-based difficulty update method. Rather than reacting to single-block samples, the algorithm computes average block time and uncle rate over the last NNN blocks. Uncle rate only influences difficulty when it crosses a specified threshold, allowing the system to prioritize main chain block timing while still preserving safeguards against instability.

This proposal builds upon the ideas in RSKIP77, which introduced smoothing via windows, but RSKIP517 further decouples uncle rate from regular difficulty adjustments.

It also replaces RSKIP491, addressing the same objective—progressively reducing block intervals—through a more robust adjustment mechanism. The open question from that thread regarding the impact on protocols remains, and further exploration is still encouraged.

For a higher-level overview of the motivation and proposed changes, see the accompanying article:
:open_book: Rootstock Blocks Getting Faster: Redefining Difficulty Adjustment

Open Questions for Discussion:

  1. What potential risks can we identify in reducing the block time to 20s?
  2. Apps/protocols that depends on block time?
    • PowPeg (source code)
    • FlyOver (LPs update # of blocks in UI, also source)
    • RootstockCollective DAO (do you know where to link it?)
    • Protocols like MoC and Sovryn (?.
]]> https://research.rsk.dev/t/rskip517-block-time-centric-difficulty-adjustment-with-uncle-threshold/494#post_1 Tue, 17 Jun 2025 18:23:05 +0000 research.rsk.dev-post-881 RSKIP-435: Network Upgrade Lovell Awesome to see that LOVELL is coming to mainnet this week. Can’t wait! Introducing Lovell 7.0.0 | Rootstock - Smart Contract Platform Secured by the Bitcoin Network

]]> https://research.rsk.dev/t/rskip-435-network-upgrade-lovell/459#post_5 Wed, 12 Mar 2025 11:07:37 +0000 research.rsk.dev-post-858 RSKIP-491 - Reduce target difficulty to lower average block time to 10s (DRAFT) Exactly the time relation time/finality didn’t change, If previously you had to wait 6 blocks or 3 minutes to be considered finalized, after this change, you will still need to wait the same 3 minutes, but it will involve more than 6 blocks.

I believe the correct terminology is “confirmation” and “finality.” Confirmed refers to when a transaction is first included in a block, but it remains reversible with a high probability. Finalized, on the other hand, means that the chances of reversion are negligible.

]]> https://research.rsk.dev/t/rskip-491-reduce-target-difficulty-to-lower-average-block-time-to-10s-draft/486#post_8 Mon, 10 Mar 2025 18:02:36 +0000 research.rsk.dev-post-857 RSKIP-491 - Reduce target difficulty to lower average block time to 10s (DRAFT) I can check if it’s used as standard terminology in some texts, but what I meant with that terminology is: the transaction has been recorded on the Blockchain, so whatever outcome is expected from executing that transaction is now in the blockchain (global state if you want), although probably not irreversible yet. So it is the first confirmation block that you mentioned.
Example: If you had 1 block every 30 seconds avg with blockGasLimit=X you could record Y transactions (settle them) every 30 seconds, on average assuming a controlled test. Now if the block time is every 15 seconds avg, with the same gas limit, you can settle Y transactions every 15 seconds, so it’s the double of transactions (and their outcome in the blockchain) recorded/settled in the same time window, on average . As you also described, the outcome of a transaction appears faster on the Blockchain as it settles faster now.
But in this example the finality time didn’t change (the time to consider them probably irreversible), as you decreased the block time by reducing the difficulty while maintaining the hash-rate unchanged (the effort to mine 2 blocks with the new lowered difficulty for the 15-second block should be very similar to the effort to mine 1 block for the 30-second block scenario)

]]> https://research.rsk.dev/t/rskip-491-reduce-target-difficulty-to-lower-average-block-time-to-10s-draft/486#post_7 Thu, 06 Mar 2025 20:17:10 +0000 research.rsk.dev-post-855 RSKIP-491 - Reduce target difficulty to lower average block time to 10s (DRAFT) You’re right that we aren’t improving the time/finality relationship, as it depends on the cumulative work, as you mentioned. However, we do reduce the time a user waits for the first confirmation block, which provides lighter finality with less cumulative work compared to before. By the way, I’ve never heard the term ‘transaction settlement.’ Where is that terminology used?

]]> https://research.rsk.dev/t/rskip-491-reduce-target-difficulty-to-lower-average-block-time-to-10s-draft/486#post_6 Thu, 06 Mar 2025 17:52:11 +0000 research.rsk.dev-post-854 RSKIP-491 - Reduce target difficulty to lower average block time to 10s (DRAFT) One comment regarding the purpose: " The goal is to improve transaction finality while maintaining network security and stability"
If we reduce the target difficulty and as a consequence reduce the avg block time, we are not improving transaction finality (we need more blocks now for the same cumulative work) , we’re improving transaction settlement.
I might be missing something so I’m reading your research here , in case it explains how finality does in fact get improved by this change.

]]> https://research.rsk.dev/t/rskip-491-reduce-target-difficulty-to-lower-average-block-time-to-10s-draft/486#post_5 Thu, 06 Mar 2025 17:27:55 +0000 research.rsk.dev-post-853 RSKIP-491 - Reduce target difficulty to lower average block time to 10s (DRAFT) In the case of Flyover, the amount of confirmations required for a quote to be confirmed is defined off-chain, therefore, if the RSK target difficulty is reduced, it would be needed that all the liquidity providers increase accordingly the number of confirmations they’re asking for pegout quotes. The server has a UI to make this kind of changes without restarting it so it shouldn’t be a big deal. Besides of this, I don’t see any other consideration to have regarding this topic.

All the usage of the block timestamp and block number is to compare against a particular quote and since the quotes have a relatively short lifecycle this reduction shouldn’t be a problem. Taking this into account, maybe it would be good that the LPs did this adjustment before the reduction, to prevent any risk with the quotes whose lifecycle coincides with both pre and post difficulty reduction blocks.

That was regarding the quote pegin and pegout processes. There is only one variable of the Liquidity Bridge Contract that contains a number of blocks required in the protocol which is the resignDelayInBlocks. This is the difference that need to pass between a LP resignation and the block where it is able to withdraw its collateral. This variable would need to be adjusted as well, but I don’t see any logic modifications required (source).

]]> https://research.rsk.dev/t/rskip-491-reduce-target-difficulty-to-lower-average-block-time-to-10s-draft/486#post_4 Fri, 28 Feb 2025 17:29:15 +0000 research.rsk.dev-post-852 RSKIP-491 - Reduce target difficulty to lower average block time to 10s (DRAFT) Agree, the ones that I’m aware of are:

  • PowPeg (source code)
  • FlyOver (LPs update # of blocks in UI, also source)
  • RootstockCollective DAO (do you know where to link it?)
  • Protocols like MoC and Sovryn (?.
    @josedahlquist can you help here?
]]> https://research.rsk.dev/t/rskip-491-reduce-target-difficulty-to-lower-average-block-time-to-10s-draft/486#post_3 Fri, 28 Feb 2025 15:12:22 +0000 research.rsk.dev-post-850 RSKIP-491 - Reduce target difficulty to lower average block time to 10s (DRAFT) Some protocols rely on the average block time (and the block number) to measure passed time as “avg block time * numberOfBlocks” . Most of them measure relatively large time windows where the resolution in seconds is not really that important, so using the block timestamp (which it is expected not to deviate more than 5min from the bitcoin header timestamp and, more importantly, it can’t be more than X seconds in the future according to the RSK node’s clock, where X by default is 60 seconds on mainnet) is a much better alternative in those cases. So this change will impact these contracts relying on an outdated average block time, especially when the time difference accumulates in time windows composed of a large number of blocks (in those scenarios the time difference can be important)
We need to identify these contracts and if they can be upgraded move to a timestamp solution to keep track of these time windows. The ones that cannot be upgraded are a problem, but I don’t think that’s a reason not to pursue this change.

]]> https://research.rsk.dev/t/rskip-491-reduce-target-difficulty-to-lower-average-block-time-to-10s-draft/486#post_2 Fri, 28 Feb 2025 14:20:03 +0000 research.rsk.dev-post-849 RSKIP-491 - Reduce target difficulty to lower average block time to 10s (DRAFT) Hey everyone,

I’d like to start a discussion on RSKIP-491 draft, which proposes reducing the target difficulty by 30% to lower Rootstock’s average block time from 14s to 10s. The goal is to improve transaction finality while maintaining network security and stability.

Key points of this proposal:

  • Mining pools have already optimized block template refresh times, reducing block time from 30s to ~24s.
  • A 10s block time is now feasible without compromising network security and stability.
  • This change requires modifying the difficulty adjustment calculation in RSKj, specifically in the Constants class for mainnet and here for testnet.
  • The change will require a hard fork, meaning all full nodes must update.

Open Questions for Discussion:

  1. What potential risks do you see in reducing the block time to 10s?
  2. Apps/protocols that depends on block time?
  3. What would be the best approach for rolling out this update?

Would love to hear your thoughts and feedback on how to move forward with this!

Full RSKIP Draft Proposal: RSKIPs/IPs/RSKIP491.md at master · rsksmart/RSKIPs · GitHub

]]> https://research.rsk.dev/t/rskip-491-reduce-target-difficulty-to-lower-average-block-time-to-10s-draft/486#post_1 Fri, 28 Feb 2025 13:21:30 +0000 research.rsk.dev-post-848 Oracle Chainlink-RSK integration Repo page shows that “has been archived by the owner on Sep 22, 2023. It is now read-only.” Any recent news about the pointed integration? It stills usable?

]]> https://research.rsk.dev/t/oracle-chainlink-rsk-integration/69#post_4 Sun, 09 Feb 2025 09:33:18 +0000 research.rsk.dev-post-844 RSK RPC Nodes Management Tools Hey, Rootstock Community! Today I’d like to tell you how to manage your RPC nodes to get the best performance and the lowest downtimes possible. We will take the GetBlock RPC node provider as an example as they support Rootstock RPC nodes on Mainnet and Testnet. We are gonna learn how they manage their high-speed RPC, and discover some services for node management, handy tools, tips, and tricks
Let’s jump right into it!

How GetBlock - RPC Provider Works

When running an RPC node it’s crucial to be always aware of the consistency and availability of your node. To do so, you have to utilize some robust management and monitoring tools. Here’s an example of the tools GetBlock is using:

  • Prometheus open-source monitoring system
  • Grafana observability platform; (the latter sources data from the first one.)
  • The health sidecar
  • Alertmanager service in Slack
  • Loadservice
  • Auto-switching system

Prometheus gathers metrics and databases to display in Grafana. Prometheus is also bonded to Alertmanager service to inform the team in Slack about all events regarding infrastructure status. The health sidecar helps GetBlock monitor the current height and health of the nodes. To get immediate notifications from the monitoring tool GetBlock connected it to the Alertmanager service in Slack. It helps to get the fastest notification if some issue occurs and always double-check when it’s resolved. The health sidecar is also connected to the auto-switching system. So if the block deviation occurs, the unhealthy node is instantly switched to a healthy one. The last but not the least important thing is to keep the node updated to the latest versions. This way GetBlock constantly monitors blockchains’ GitHub repositories and social medias to find out about the upcoming updates first in hand.
All of that helps GetBlock to reach the highest node availability of 99%!

If you don’t wanna experience all the hustles associated with running and maintaining your Rootstock RPC node. You can simply connect to RPC nodes for 50+ blockchains with GetBlock. It’s now even available with 30% OFF for your first shared node subscription.

source: Rootstock Node: Web3 RPC RSK nodes API | GetBlock.io

RPC Nodes Management

]]> https://research.rsk.dev/t/rsk-rpc-nodes-management-tools/478#post_1 Tue, 24 Sep 2024 16:54:25 +0000 research.rsk.dev-post-839 Convenient script for quickly generating transactions containing data Thank you very much!

I apologise again for the delayed response. I was waiting for confirmation on the shipment of a key piece of equipment. Unfortunately, the optics were unavailable due to a force majeure, causing a multi-month delay.

The silver lining is that this gave me the opportunity to rebuild my code from scratch in a cleaner environment, free of conflicting dependencies. It’s all running much more smoothly now.

The final component has just arrived in the EU and will be in Ireland next week, allowing me to finally release the demo.

Thank you again for your understanding and attention. I hesitated to make predictions earlier due to the unavoidable delays, but we’re now on track.

]]> https://research.rsk.dev/t/convenient-script-for-quickly-generating-transactions-containing-data/393#post_5 Thu, 29 Aug 2024 17:59:44 +0000 research.rsk.dev-post-832 RSKIP-435: Network Upgrade Lovell Yes, exactly this @GoldenGatsby. The idea with proposed RSKIP are exactly to make it more compatible with Ethereum. This way, users will be able to migrate their contracts or improve the existing ones, to the Rootstock network and get advantage from the cheaper and secure environment. :slight_smile:

These RSKIP also make the network more fair, since it will update a bit the costs for contracts with bigger initcode size. :tada:

]]> https://research.rsk.dev/t/rskip-435-network-upgrade-lovell/459#post_4 Fri, 23 Aug 2024 16:56:20 +0000 research.rsk.dev-post-829 RSKIP-435: Network Upgrade Lovell Thanks, @GoldenGatbsy! Keeping compatibility with the EVM is always a top priority.

]]> https://research.rsk.dev/t/rskip-435-network-upgrade-lovell/459#post_3 Wed, 21 Aug 2024 13:16:26 +0000 research.rsk.dev-post-819 Convenient script for quickly generating transactions containing data Cool! Did you check out the developer portal? It recently had a big redesign and the AI support tool is great for questions like this.

Web3.py is great for interacting with Rootstock: Deploy and Interact with a Smart Contract using Web3.py | Rootstock Developers Portal

]]> https://research.rsk.dev/t/convenient-script-for-quickly-generating-transactions-containing-data/393#post_4 Wed, 21 Aug 2024 10:03:52 +0000 research.rsk.dev-post-818 RSKIP-435: Network Upgrade Lovell More Ethereum compatibility is always a good thing! Interested to hear what others think of the individual RKSIPs.

]]> https://research.rsk.dev/t/rskip-435-network-upgrade-lovell/459#post_2 Wed, 21 Aug 2024 10:00:09 +0000 research.rsk.dev-post-815 RSKIP-435: Network Upgrade Lovell Hello to the Rootstock community! :wave:

A network upgrade proposal has been recently published and is open for discussion. This proposal focuses mostly on Ethereum compatibility by introducing opcodes already supported by the Ethereum Virtual Machine and the introduction of the PowPeg Spendability Validation Protocol.

Here are the key proposed improvements slated for inclusion in Lovell:

  • RSKIP-419: PowPeg Spendability Validation Protocol
  • RSKIP-427: Express the amount value in wei for peg-out related events
  • RSKIP-428: New pegout creation event including UTXO outpoint values
  • RSKIP-438: Limit the maximum size of initcode and apply extra gas cost for every 32-byte chunk of initcode
  • RSKIP-445: MCOPY instruction
  • RSKIP-446: Transient storage opcodes

This proposal is an initial step. We invite the community to engage in open discussions, share insights, and propose additional improvements. Your feedback is crucial to shaping Rootstock’s future.

Thank you!

]]> https://research.rsk.dev/t/rskip-435-network-upgrade-lovell/459#post_1 Tue, 13 Aug 2024 19:56:17 +0000 research.rsk.dev-post-814 RSKIP-436: Network Upgrade (patch) Arrowhead 6.3.1 Hello to the Rootstock community! :wave:

A patch network upgrade proposal has been recently published and is open for discussion. This proposal aims to fix the PowPeg service outage described in " Incident report: Rootstock peg-in / peg-out service outage on June 24th".

Arrowhead 6.3.1 proposal includes only one RSKIP, which describes a short to mid-term fix to the issue and aims to resume normal PowPeg operations as quickly as possible. A long-term solution is currently being discussed.

  1. RSKIP-434 : : Bridge Bitcoin block chainwork up to 12 Bytes

We invite the community to engage in open discussions, share insights, and propose alternative improvements if necessary. Due to the nature of this network upgrade and the need to resume PowPeg operations soon, this RSKIP will be open for comments until July 9th.

Thank you!

]]> https://research.rsk.dev/t/rskip-436-network-upgrade-patch-arrowhead-6-3-1/458#post_1 Thu, 04 Jul 2024 18:10:05 +0000 research.rsk.dev-post-813 Convenient script for quickly generating transactions containing data Thank you for responding! Apologies for the latency in my response; I was working on another component of the project :smiley:

I was in a hurry for a python-native library for easily generating transactions from a private key with little configuration and overhead. I found a solution which suited me; issuing a token using brownie.

If there’s a default Python library for interacting with Rootstock, now would be a good time for me to switch over. May I ask whether there any commonly used Python-based solutions?

]]> https://research.rsk.dev/t/convenient-script-for-quickly-generating-transactions-containing-data/393#post_3 Sun, 21 Apr 2024 20:56:37 +0000 research.rsk.dev-post-809 Convenient script for quickly generating transactions containing data Hi Ortho - Did you discuss this with the Discord community? Or are you still looking for help?

]]> https://research.rsk.dev/t/convenient-script-for-quickly-generating-transactions-containing-data/393#post_2 Wed, 17 Apr 2024 13:17:10 +0000 research.rsk.dev-post-807 Rootstock Analytics Hey,

I work with PYOR, a blockchain analytics firm backed by Coinbase and Castle Island Ventures. We have worked with protocols like Compound, Tezos, Quickswap, and ICP to build custom analytics dashboards and research reports.

We have worked very closely with the foundation/community to cater to their data needs, as we’ve realized that there is no one-size-fits-all solution, it varies based on the protocol’s stage and needs.

Wanted to check with the Rootstock community/foundation to understand what metrics/data points you track or would like to track, so we can build dashboards/reports that cover these metrics. Happy to share our past work as well so you can gauge our capabilities.

Cheers,

]]> https://research.rsk.dev/t/rootstock-analytics/450#post_1 Wed, 17 Apr 2024 10:48:19 +0000 research.rsk.dev-post-803 RSKIP419 - Powpeg Spendability Validation Protocol
Rootstock Improvement Proposals
]]> https://research.rsk.dev/t/rskip419-powpeg-spendability-validation-protocol/446#post_3 Mon, 15 Apr 2024 09:44:23 +0000 research.rsk.dev-post-801 RSKIP419 - Powpeg Spendability Validation Protocol Can you share a link to the proposal?

]]> https://research.rsk.dev/t/rskip419-powpeg-spendability-validation-protocol/446#post_2 Fri, 12 Apr 2024 13:49:41 +0000 research.rsk.dev-post-799 RSKIP419 - Powpeg Spendability Validation Protocol Hello everyone, we would like to share with the Rootstock community RSKIP419. It introduces an automatic validation to be performed by the Bridge whenever a powpeg composition change is voted, to make sure that the new proposed Powpeg is able to securely store the funds locked in Rootstock. It aims to enhance the security of the Rootstock 2 way peg.

Your feedback is most welcome. Thanks!

]]> https://research.rsk.dev/t/rskip419-powpeg-spendability-validation-protocol/446#post_1 Wed, 10 Apr 2024 10:29:25 +0000 research.rsk.dev-post-797 RSKIP-414: Network Upgrade Arrowhead A new RSKIP has been proposed by the IOVlabs team to be included in Arrowhead. This RSKIP proposes that, when a Bridge method is called from a smart contract and returns an empty value, then no exception is thrown, and the transaction is not reverted.

Details here: RSKIP417 - Avoid transactions to be reverted when Bridge method calls from smart contracts return an empty response

]]> https://research.rsk.dev/t/rskip-414-network-upgrade-arrowhead/419#post_5 Mon, 04 Mar 2024 22:02:11 +0000 research.rsk.dev-post-774 RSKIP-414: Network Upgrade Arrowhead A new RSKIP has been proposed by the IOVlabs team to be included in Arrowhead. This RSKIP proposes a change in how the Rootstock address of the pegnatories is derived from their public key, fixing an issue by which some pegnatories are not receiving the corresponding network fees in the correct Rootstock address.

Details here: RSKIPs/IPs/RSKIP415.md at master · rsksmart/RSKIPs · GitHub

]]> https://research.rsk.dev/t/rskip-414-network-upgrade-arrowhead/419#post_4 Fri, 16 Feb 2024 05:10:02 +0000 research.rsk.dev-post-773 RSKIP-414: Network Upgrade Arrowhead This proposal is being discussed on the latest community call Twitter (X) / YouTube

]]> https://research.rsk.dev/t/rskip-414-network-upgrade-arrowhead/419#post_3 Thu, 18 Jan 2024 14:34:47 +0000 research.rsk.dev-post-772 RSKIP-414: Network Upgrade Arrowhead I agree with the proposals that were selected for the next network upgrade. However, I have a comment related to RSKIP-400.

I hope that in a future upgrade we can do something better than the calldata gas reduction. I understand that currently there is a need to compete with other blockchains that provide a data availability layer for rollups, but we should not compromise RSK core function which is to serve for financial transactions, and reducing the cost of calldata may prevent us from increasing the block gas limit. So we may be shooting ourselves in the feet.

The other use case for blockchain data, which is inscriptions, is not considered in RSKIP-400. Bitcoin inscriptions have proven that they are not sensible to transaction fees. People are paying hundreds of dollars to inscribe in Bitcoin. Rollup data, on the contrary, is very sensible to price. However, the RSKIP-400 helps rollups but doesn’t mention the drawback that it reduces the cost of inscriptions/NFT spam.

RSKIP-281 (and the previous ephemeral data proposals in the RSKIP repository) were specially optimized for rollup payload.

So even if we activate RSKIP-400, we should look for better alternatives in the future.

]]> https://research.rsk.dev/t/rskip-414-network-upgrade-arrowhead/419#post_2 Tue, 09 Jan 2024 20:08:45 +0000 research.rsk.dev-post-769 RSKIP-414: Network Upgrade Arrowhead Hello to the Rootstock community! :wave:

A network upgrade proposal has been recently published and is open for discussion. This proposal focuses mostly on Ethereum compatibility by introducing opcodes already supported by the Ethereum Virtual Machine.

Here are the key proposed improvements slated for inclusion in Arrowhead:

  1. RSKIP-203: Introducing the GetCallStackDepth precompiled contract.
  2. RSKIP-376: Version 2 designation for PowPeg migration transactions.
  3. RSKIP-379: Indexing for Bridge peg-out and migration transactions.
  4. RSKIP-398: Introducing the PUSH0 opcode.
  5. RSKIP-400: Reduction in calldata gas costs.
  6. RSKIP-412: Introducing the BASEFEE opcode.

This proposal is an initial step, and we invite the community to engage in open discussions, share insights, and propose additional improvements. Your feedback is crucial to shaping the future of Rootstock.

Furthermore, we anticipate hosting a community call in January 2024 to delve deeper into these proposed changes.

Thank you!

]]> https://research.rsk.dev/t/rskip-414-network-upgrade-arrowhead/419#post_1 Tue, 19 Dec 2023 13:47:48 +0000 research.rsk.dev-post-765 Triple RPS Boost to Maximize Dapp Performance in the Bull Market To all Rootstock Devs,

Please be informed of a technical update on GetBlock, an RPC Node Providing service. The rate limit for all shared plans of Rootstock Nodes will be increased from 60 to 200 requests/second (RPS). This update is part of ongoing service enhancements.
It is important to note that this RPS increase applies solely to users who have migrated to access tokens. Users currently employing API keys and wishing to benefit from the higher rate limit must migrate to access tokens.
For detailed instructions on the migration process, refer to the instructions available in your account.

Regards,
GetBlock Technical Team

]]> https://research.rsk.dev/t/triple-rps-boost-to-maximize-dapp-performance-in-the-bull-market/418#post_1 Thu, 14 Dec 2023 12:10:49 +0000 research.rsk.dev-post-764 Rootstock Development Tools

F_8mnosXsAA12kI

If you’re working on the Rootstock blockchain, exploring its latest developer tools can significantly enhance your experience

  • RSKj: Core Platform- Java-based RSK protocol implementation

  • RBank Tools for DeFi-Tools for building DeFi products on RSK

  • Tenderly Integration-Monitor and enhance smart contracts on Rootstock
    tenderly-support

Development Frameworks and Tools:

  • Truffle for RSK: Simplify smart contract deployment

  • GitHub Community: Collaborate on RSK projects.
    rsksmart

RSK Pre-compiled ABIs Explorer: Interact with RSK’s ABIs

Need a node? With GetBlock.io, you can connect to a shared/dedicated RSK node without the hassle of setting up and maintaining one yourself. This service is ideal for those who seek ease of use and minimal setup.

]]> https://research.rsk.dev/t/rootstock-development-tools/417#post_1 Mon, 27 Nov 2023 20:30:14 +0000 research.rsk.dev-post-763 RSK <> GetBlock AMA Session Really cool, thank you for saving such interviews, is there also a written recap?

]]> https://research.rsk.dev/t/rsk-getblock-ama-session/391#post_2 Mon, 13 Nov 2023 13:36:36 +0000 research.rsk.dev-post-760 Solutions on RSK: Hardware Needs and Service Provider Benefits GetBlock is a service that provides a fast and easy connection to RSK nodes, and a continuously growing list of over 50 blockchains. In order to build a blockchain-based application, an individual or a company usually has to deploy and run several blockchain nodes. There is no need to launch and support all the nodes any more as the GetBlock service will get access to all the available currencies automatically. In order to get started with GetBlock, clients of the platform have to register an account and receive an API key which will be displayed on the dashboard together with the related data.

Typical hardware requirements for running a Rootstock node might include:

A modern version of Windows, Mac OS X, or Linux operating system.
A minimum of 500 GB of disk space with a fast read speed, preferably on an SSD to ensure efficient processing of blockchain data.
At least 8 GB of RAM to handle the node’s operations effectively.
A stable broadband internet connection with high download and upload speeds, and sufficient data allowance.
Operating nodes on networks like Ethereum requires specific technical skills, and this is also true for Rootstock nodes. Different synchronization modes may be available for RSK, similar to Ethereum’s fast, full, and light modes, with each mode offering different trade-offs in terms of speed and data requirements.

GetBlock’s Goal

The goal of GetBlock is to provide users with access to full nodes from RSK, and many other leading blockchain platforms, allowing them to request on-chain information from a node without the need to set up one manually.

GetBlock guarantees a fast and stable connection to the RSK nodes by providing a turnkey infrastructure solution, so that a developer can easily integrate the RSK technology to the project without worrying about troubleshooting, updates, and constant syncing.

Features

Users of GetBlock will have a personal account with the following features included:

  • All available blockchain nodes
  • Unlimited number of API keys
  • Rate limits of 10 requests/sec (auto-scaling is in the roadmap)
  • High connection speed at 1GB/sec
  • Trace+Archive
  • Advanced analytics
  • Automated updates
  • Technical support

GetBlock is a complete solution for developers who don’t need to wait hours and hours for the RSK node to be synced, as the platform provides a cost-effective infrastructure that guarantees a fast and reliable connection to a blockchain via full nodes.

Components

GetBlock provides instant access to RSK nodes over HTTPS. It supports such APIs as REST, JSON-RPC, WebSockets and IRI, which facilitates the whole process of building decentralized applications (dApps).

GetBlock - ConnectionImage

Why choose GetBlock?

  • End-to-end solution — easy setup and fast integration of the RSK node to your app, automated node updates, and maintenance
  • Always evolving — list of accessible nodes is always expanded, with new nodes added based on clients’ requests
  • Reliable connection — most GetBlock servers are located in Germany, working 24/7 to provide reputable work and fast connection to the RSK node
  • Helpful data — all the related information on statistics and parameters for the RSK node is displayed in real-time
  • On-demand support — our team of experts guarantee fast consulting and personal support for both beginners and experienced developers
  • Privacy — the service doesn’t keep or ask for any information about keys, wallets, or any other private data. It receives from the clients only the encrypted transactions

RPC Endpoints

RPC via GetBlock

]]> https://research.rsk.dev/t/solutions-on-rsk-hardware-needs-and-service-provider-benefits/414#post_1 Mon, 13 Nov 2023 13:22:16 +0000 research.rsk.dev-post-759 Support For Bridging Bitcoin Stamps Bitcoin Stamps are a type of digital collectible that is stored on the Bitcoin blockchain. They are created using the Counterparty protocol, which allows for the creation of assets and tokens on top of the Bitcoin network.

Bitcoin Stamps are created by encoding an image into a Base64 string and then storing that string in a Counterparty transaction. The transaction is then broadcast to the Bitcoin network and, once it is confirmed, the Bitcoin Stamp is created.

Bitcoin Stamps can be bought, sold, and traded on a variety of exchanges and marketplaces. They can also be used to create other types of digital assets, such as non-fungible tokens (NFTs).

Bitcoin Stamps have a number of advantages over other types of digital collectibles. First, they are stored on the Bitcoin blockchain, which is a very secure and decentralized network. Second, Bitcoin Stamps are relatively easy to create and transfer. Third, there is a growing community of collectors and traders who are interested in Bitcoin Stamps.

Here are some of the things that you can do with Bitcoin Stamps:

  • Collect them as digital art
  • Use them to create other types of digital assets, such as NFTs
  • Trade them for other Bitcoin Stamps, cryptocurrencies, or fiat currencies
  • Use them to pay for goods and services from merchants who accept Bitcoin Stamps

There is only one layer 1 chain marketplace selling Bitcoin Stamps,

  • RareStamp.xyz: This is a marketplace dedicated to Bitcoin Stamps. It allows you to buy and sell individual stamps and collections.

There is only one layer 2 chain that are supporting Bitcoin Stamps,

  • Emblem Vault is a non-custodial Bitcoin Stamps vault that also supports wrapping Bitcoin Stamps on Ethereum and Polygon. It was launched in April 2023 and is still under development.

My proposal

Bitcoin Stamps hasn’t gain as much traction as ordinals did but it is currently getting some fud in regards to inscription numbers. I propose that we build a bridging platform for Bitcoin Stamps on Rootstock. This would allow Bitcoin Stamp collectors and traders to benefit from the advantages of both platforms, including:

  • The security of the Bitcoin blockchain
  • The smart contract functionality of Rootstock
  • The ability to trade Bitcoin Stamps on a variety of marketplaces

Benefits

There are a number of benefits to building a bridging platform for Bitcoin Stamps on Rootstock:

  • Increased liquidity: The Bitcoin Stamp market is relatively illiquid. By bridging Bitcoin Stamps to Rootstock, we can increase the liquidity of the market and make it easier for people to buy and sell Bitcoin Stamps.

  • Wider reach: Rootstock is a growing ecosystem with a number of decentralized applications (DApps) and marketplaces. By bridging Bitcoin Stamps to Rootstock, we can expose Bitcoin Stamps to a wider audience of potential buyers and sellers.

  • New features: Rootstock smart contracts can be used to create new features and functionality for Bitcoin Stamps. For example, we could create a marketplace where Bitcoin Stamps can be traded for other cryptocurrencies or fiat currencies. We could also create a system where Bitcoin Stamps can be used to access exclusive content or services.

For more information about STAMPS Protocol, please visit the project’s GitHub page at https://github.com/mikeinspace/stamps/blob/main/README.md .

]]> https://research.rsk.dev/t/support-for-bridging-bitcoin-stamps/410#post_1 Wed, 20 Sep 2023 14:01:43 +0000 research.rsk.dev-post-755