Pagoda Pauses the B.O.S. Web Engine R&D Project

After careful consideration, Pagoda has decided to discontinue its active efforts to improve the B.O.S. Web Engine

After many discussions with NEAR’s B.O.S. component developers and careful consideration, Pagoda has decided to discontinue its active development for B.O.S. Web Engine R&D for an improved execution layer for NEAR B.O.S. Components. (also known as “BWE” & “VM2”)

Background

Last year, NEAR introduced the Blockchain Operating System, demonstrating how NEAR’s performant tech stack could support a full-stack decentralized development platform that was multi-chain compatible. A core feature of this system consisted of composable decentralized front-ends (B.O.S. Components) paired with a user-centric data storage contract (social-db). This model, pioneered by NEAR Social, aimed to continue NEAR’s mission of empowering users to own their data as well as eliminate reliance on centralized, single-entity-controlled web applications. The potential of a fully decentralized web and the creation of real dApps became closer to reality with these inherently open and customizable experiences.

As the community started to adopt B.O.S. it soon became clear that, while devs loved how fast it was to go from an idea to a product, its intrinsic technical limitations made it hard to use B.O.S. for any real-world application. This consistent feedback from multiple members of the community prompted Pagoda to start an R&D effort to improve B.O.S. such that:

• It was as close to vanilla React as possible
• Supported npm package imports
• Unlocked multi-chain scalability limitations
• Improved performance
• Improved security

B.O.S. Web Engine

In order to act on this feedback and accomplish these goals, improvements had to be made to the execution layer that makes this all possible. At its core, a virtual machine, (NEAR Social VM) renders front-end code that developers store in a smart contract onchain (social-db). It was determined that a new approach to the original VM solution was needed, and the B.O.S. Web Engine project was created. Countless hours of hard work and dedication have gone into this project, yielding many significant achievements along the way. However, one major challenge still stands in the way of a production-ready beta release: expanding support for npm packages, particularly UI libraries.

During the alpha testing phase of this project, we anticipated a fairly straightforward path in resolving wider npm support but unfortunately, the team discovered a more complex scenario. While standard JavaScript packages work well, React UI libraries frequently encounter difficulties. These challenges stem from the unique packaging methods of each library and the complexities involved in synchronizing changes between the iframe and the outer DOM. Although we have identified several theoretical solutions, each requires further research and development to assess their practicality and effectiveness. This has been more fully detailed in a GitHub discussion within the BWE Repo.

We reached out to leading B.O.S. component contributors to determine whether this limitation would be unnegotiable and to learn what features they value most. Do they prioritize unrestricted NPM support over secure iframe composability? How important is composability, and how would they define it? (considering our approach dissects it down to the atomic level of every element)

This revealed some interesting findings, one of which was that secure composability on an atomic level was not at the top of the list. Most favored the ease of quick prototyping, deployment, and onboarding with managed infra and wallet connections. Many valued social-db features and the ability to create custom gateways (websites) using code and user data publicly available to them.

In short, there were three camps:

True Believers

• Decentralize all the things!
• Love bleeding-edge unique tech
• Love inherent open-source
• Love social-db and its features

Quick Builders

• Love the speed of development, prototyping, remixing
• Love reverse engineering existing components
• Quick onboarding with managed infra and wallet connections
• Great for hackathons

Detractors

• Don't like anything about B.O.S. components
• DevX is poor and UI is slow
• Value convenience over decentralization

After reviewing our findings and engaging extensively with developers using this platform, it became clear that continuing with the release of the B.O.S. web engine as currently planned could potentially have a net negative impact. The majority of developers indicated that they do not favor a version of the BWE with limited npm support, even if it means enhanced secure composability. Additionally, while a minority of builders prioritize decentralization over performance and convenience, those who truly value decentralized frontends might find simpler ways to achieve their objectives once the need for secure composability is eliminated.

For those who may disagree with this perspective, the B.O.S. Web Engine remains, and will always be an open-source project. Anyone who sees value in the work we have done and wishes to advance this initiative is welcome to carry this torch and continue the development. https://github.com/near/bos-web-engine

What does this mean for B.O.S. components & the current VM?

During the development of the B.O.S. Web Engine, a large focus was placed on addressing the security aspects of the existing VM and B.O.S. component architecture. The primary concern is with the composability and attack vectors that are exposed when importing components authored by third parties. Despite numerous patches to address discovered exploits, the inherent complexities of JavaScript and the current VM’s architecture suggest that such vulnerabilities may continue to persist. Pagoda has diligently monitored and addressed these issues to date but we anticipate challenges in continuing to proactively discover and mitigate future vulnerabilities.

For examples of previously discovered vulnerabilities, view the VM changelog going back to v2.5.1, paying attention to lines tagged as FIX on issues Reported by BrunoModificato from OtterSec.

If you find value in creating B.O.S. components and leveraging the features of the social-db smart contract, rest assured that this framework will remain open-source and permanently accessible on-chain. However, we urge caution when incorporating and using third-party components. Due to the current virtual machine's limitations, we cannot guarantee protection against potential future exploits.

Should I migrate my project off of B.O.S.?

If your application relies on community-contributed or unreviewed third-party components, then yes. As described above, we cannot guarantee protection against future security vulnerabilities in the VM and B.O.S. component architecture. However, you can mitigate (but not eliminate) these security risks by reviewing all third-party components and either forking them or locking down dependencies to the specific version that you reviewed.

If you are not relying on any untrusted component code, then maybe. You are not being forced to migrate and there are still teams actively building new applications leveraging B.O.S. Additionally, there are no plans to deprecate main B.O.S. gateways at dev.near.org, near.social, dapdap or bos.gg. However, the underlying framework and virtual machine are no longer actively developed or maintained by the original team. Consequently, the pace at which new features are introduced and existing bugs or vulnerabilities are addressed may be slower than expected. We openly welcome new maintainers for this codebase. However, as previously mentioned, we anticipate that additional security vulnerabilities may still be discovered.

We have updated “Frontends for Web3 dApps” in docs.near.org to help you choose a solution that is right for you. If you need help, please reach out to one of our support channels on Telegram or Discord and we will be happy to assist you or answer any questions you have.