The MONADIC.US Blog with news and updates on all the things we are working on.

  • For Aleo, And Life, Trust Is Not a Choice

    “Faith fills the gap where empirical knowledge cannot reach.”

    –Immanuel Kant

    Trust is rooted in evidence and experience. It emerges naturally and subconsciously when evidence is consistent and reliable. A deliberate denial of trust feels like self-deception because it contradicts lived reality.

    For open source developers working on Aleo, the lived reality must be one that demonstrates consistent and reliable evidence there’s no proprietary exploitation or corporate agenda, that the protocol is sustainable with constant ecosystem growth which is prioritized over short-term profits, and that it can resist pressures like shareholder demands or profit maximization strategies for single individuals or companies that may conflict with community interests.

    The Aleo Foundation spent considerable time and resources building the infrastructure for it to manage and maintain the core source code. Before this happened, there were considerable barriers to open-source participation as community contributions regularly floundered. For the community of contributors, it was a breath of fresh air as transparent governance took root.

    It is our hope that this continues. We believe transparency, auditability, and fair open-source governance will continue to be the standard for Aleo. The investment in broad ecosystem development that benefits everyone must continue.

    non-profits benefit open source projects

    Using a non-profit organization to own and manage cryptocurrency code repositories can provide several benefits, particularly for projects aiming to foster community trust, decentralization, and sustainable growth.

    Here are the key advantages:

    1. Enhanced Trust and Credibility

    • Neutral Stewardship: Non-profits are perceived as impartial entities that prioritize the project’s mission over profit-making. This fosters trust among developers, users, and investors.
    • Transparency: Non-profits are often required to operate transparently, providing financial and operational disclosures that can reassure the community about the project’s governance.

    2. Alignment with Decentralization Goals

    • Avoiding Centralized Control: Non-profits can act as custodians for repositories, ensuring no single for-profit entity has undue influence over the code or development direction.
    • Encouraging Community Contributions: Community members may feel more comfortable contributing to a project owned by a non-profit, as there is less concern about proprietary exploitation or corporate agendas.

    3. Sustainability and Long-Term Focus

    • Mission-Driven Development: Non-profits are more likely to prioritize long-term goals, like protocol sustainability or ecosystem growth, over short-term profits.
    • Resilience Against Corporate Pressure: By separating repository ownership from for-profit entities, projects can resist pressures like shareholder demands or profit maximization strategies that may conflict with user interests.

    4. Reduced Regulatory Risks

    • Lower Perception of Securities Risk: Projects managed by non-profits may be less likely to face accusations of issuing securities, as they can emphasize their decentralized and non-commercial nature.
    • Regulatory Shielding: A non-profit structure signals a focus on community and public benefit, which can mitigate regulatory scrutiny compared to for-profit corporations.

    5. Encouraging Broader Ecosystem Collaboration

    • Open Governance: A non-profit can establish collaborative decision-making frameworks, encouraging participation from diverse stakeholders, including businesses, developers, and academics.
    • Funding Opportunities: Non-profits can attract grants and donations from other non-profits, government agencies, or philanthropic organizations, which may not be available to for-profits.

    6. Mitigation of Fork Risks

    • Reduced Perception of Exploitation: With a non-profit custodian, there is less risk of a community or developer fork due to perceptions that the project’s codebase is being exploited for private gain.
    • Centralized Neutrality: A non-profit ensures that changes or updates to the repository are evaluated based on merit rather than profit motives, reducing conflict within the ecosystem.

    7. Tax and Funding Advantages

    • Tax-Exempt Status: Many non-profits qualify for tax-exempt status, reducing operating costs and enabling more resources to go toward development.
    • Diverse Funding Sources: Non-profits can leverage a broader range of funding models, including donations, grants, and partnerships, which may not be as readily available to for-profits.

    examples of successful non-profit models

    • Ethereum Foundation: Ensures Ethereum’s development remains decentralized and mission-driven, even as for-profits like ConsenSys contribute heavily to the ecosystem.
    • Stellar Development Foundation: Oversees the development of Stellar with a focus on financial inclusion, avoiding profit-driven decisions that could harm its mission.
    • Interchain Foundation (Cosmos): Manages the development of Cosmos while encouraging participation from for-profits like Tendermint Inc.

    challenges to consider

    • Funding Stability: Non-profits may struggle to secure consistent funding without the revenue streams available to for-profits.
    • Operational Bureaucracy: Decision-making can become slower in non-profits due to a need for consensus and adherence to governance processes.
    • Dependency on Key Individuals: Non-profits often rely on founding members or initial donors, which can lead to vulnerabilities if these individuals leave or withdraw support.

    Using a non-profit to own the repositories is particularly beneficial for projects that prioritize decentralization, community trust, and regulatory compliance. However, the choice ultimately depends on the project’s goals, governance preferences, and funding strategies.

    demonstrating trust

    Now, the community will be observing what is demonstrated by the Foundation and those that contribute to the project. Every observer will not have a choice, as elaborated in the preamble of this post, about whether or not to trust the governance of the Aleo project, even if they desperately, in their heart of hearts, desire to do so. If the Foundation and the core contributors have demonstrated deliberate, transparent actions worthy of trust, then the community and ecosystem will indeed act in accordance to that unquestionable trust.

    If, however, self-interested parties who do not have the best interests in mind of the overall success of the community deliberately gate-keep, hide, or fail to drive the project forward by rejecting transparent open-source governance, then trust will have been destroyed or made impossible. Contributing developers will face the feeling of self-deception in choosing to contribute to a project that clearly does not have the best interests of the community in mind. They will devote their efforts elsewhere. The Aleo project will fail.

    We at MONADIC.US will continue to act in good faith in order to build the trust of the community. We will strive for open governance and transparent contribution. It is our hope that the Aleo Foundation continues to endeavor to make transparency, auditabiltity, and positive contributor responsiveness an utmost priority for the project.

    +
    + ,

  • For Aleo, Startup Time is Table-stakes

    When I was running Mozilla Firefox engineering, mobile apps had recently been launched by Apple. The Android store was emerging. Android was quickly gaining traction.

    I kept in touch with Mark Zuckerberg and Andy Rubin (guy who started Android, sold it to Google, etc.) to keep my finger on the pulse of key adopters we must win to keep the Web as a first class citizen of the Internet.

    A big threat for Firefox was closed markets like app stores which locked out the Web as a platform from mobile devices completely. To put it in perspective, fast forward to today: The Web has been taken over by mobile apps. People spend more time now in native apps than the Web itself. This is now the case, and it was what I had to keep from happening. We all failed. The Web took a bullet.

    So, I went to the number one app on the planet at the time: Facebook. I met with Mark Zuckerberg, and I asked him my most important question:

    “What would it take for you to use the Web as a platform for the Facebook app instead of native libraries?”

    His answer:

    “Startup time is terrible. The most important thing for us is to get the content the user cares about in front of their eyeballs as fast as possible, and starting up a Web app on mobile is 50 times slower than just using a native app.”

    He was totally right. The overhead of just loading up a Web page, with all the the styling and displaying CSS, and the dynamic elements that Javascript creates was a huge amount of overhead that slowed everything down. And, I also knew at that very moment that the Web was at least two years behind in performance, even with 500 engineers on my team building the Web. I was crushed.

    Facebook developers just refused to use the Web because it took too much time to start the app, test the content (i.e., timelines and photos), and then shut down the app (not to mention crashes on mobile which happens all the time).

    App developers (all software devs really) have a critical set of tests called T/s. Which means Time for Startup. They often have thousands of specific test cases that are run automatically every time a code change is made, and T/s is checked every single time for regressions. If someone adds in an animation to a startup splash screen for an app, T/s goes up, and that’s a regression.

    Every time T/s goes up, thousands and thousands of users are lost. Not kidding. This is real.

    What’s the first thing a potential Aleo developer will do? They will download Aleo software and run it. What’s the only software they can run today? snarkOS. That’s right. snarkOS is the ONLY thing they can run, and it’s the FIRST impression that will be made. And their FIRST impression: T/s.

    Before a developer can do anything on Aleo, they will have to run a node. And what contributes to startup time for a node? SYNC. It has to pull down the chain before anything will work. Ever.

    We just celebrated on Twitter our “One Million Blocks!” and when I read that tweet, I felt a cold chill. That means, before anyone can use Aleo, they have to download 1,000,000 blocks.

    Imagine taking that requirement to a Facebook dev whose main priority is app performance, and say, “Hey, add this feature into Facebook, oh, you’ll need to check out their node first and run it.” And when they do, they see that it literally takes DAYS to start. Aleo is dead. Right. There.

    Step one for Aleo: Create a T/s goal of “Sub-sixty second startup time.”

    And, really, that’s not enough. It should be sub-ten second, but let’s start with something I think we could hit.

    In my proposed Aleo Technical Roadmap: That goal is encapsulated here in Phase 1: Stability and Scalability, Item 1. Network Optimization and Performance Enhancements, Bullet One: Improve Node Synchronization. It’s table-stakes.

    Important: When we were testing Aleo network mainnet requirements, we had to create reproducible tests, and that meant that we had to work around the whole startup time problem entirely. We couldn’t run a test over and over again and each time wait for a sync to finish so we could run the test again. Just wasn’t feasible. So, what did we do?

    We built tooling which eliminated the sync problem entirely: We started the entire network from scratch each time using special tools which generated a new genesis block (which could be re-used) and spawned a new topology.

    We maniacally chiseled down to just what was required to rapidly start a network, deploy an app, test it, and stop. Rinse repeat. All done in seconds.

    This enabled us to create other test suites which tested our specific zkApp functionality reliably and repeatably.

    Today, without that tooling, a potential Aleo developer would just give up and leave. And Aleo’s network wouldn’t be live on mainnet because that’s what it took for us to find the critical threading issue that was crippling all canary nodes and killing them in seconds from startup, over and over and over again.

    This is why developer tools are critical.

    +

  • MONADIC.US TECHNICAL ROADMAP

    As promised, here’s a technical roadmap for MONADIC.US’ efforts to enhance Aleo’s developer ecosystem.

    We believe that the key to the success of Aleo’s network is onboarding a vast market of zkApps, and that takes developers to build them. To enable this, MONADIC.US is building snarkOps to amplify Aleo zk app developers with a rapid on-ramp to mainnet.

    Note that this roadmap addresses Phase 2 of the overall Aleo Technical Roadmap, Developer Ecosystem Expansion.

    + , , ,

  • Proposed Aleo Technical Roadmap

    I’ve proposed a Technical Roadmap for Aleo. Over the next few days, I’ll be writing about each of the sections in that roadmap and expounding on why each item is there.

    MONADIC.US has been building tools to create a rapid on-ramp for zero-knowledge app developers, and I’ll be publishing our technical roadmap next. We’ve a ton of great features which we believe will enable zk-App developers to use Aleo. We are hopeful to build on our ideas.

    In the meantime, comments and thoughts are much appreciated.

    + , ,

  • MONADIC.US as core Aleo Validator

    For the past two years, MONADIC.US has been working with Aleo to help them launch their decentralized network for zero-knowledge applications. Last month (Sept. 2024), we successfully launched mainnet, and it’s been listed on Coinbase now for over two weeks. This is a huge success for everyone in the community who worked so hard to make it real.

    Before the network launched, MONADIC.US decided to pursue becoming a core validator on Aleo’s network. We worked diligently to help them test their core validator server, snarkOS, and we built tools to enable them to pass the acceptance criteria for mainnet launch. We participated in all of the open-source Validator community meetings in which we were responsible for the thorough testing of Aleo’s network. These meetings were critical to the successful launch. Anyone wanting to become a validator had to show up and do the work. We did all we could do to make this effort a success.

    During this pre-launch phase, we were responsible for testing sync times, validator connectivity, and transaction rate testiing. All of these tests were enabled by our tools, snarkOps.

    In the months before launch, snarkOS nodes were constantly stalling and stopping sync. They could not download and process the blockchain. During high-transaction periods on the network, nodes would often only run for a few seconds before stalling. There was a critical threading issue inside of snarkOS.

    Using snarkOps, MONADIC.US developers isolated the threading issue and created a fix. This one fix unlocked the full potential of snarkOS network synchronization, and nodes across the network could fully process the entire blockchain without crashing. We are very proud of this accomplishment.

    To prepare for becoming a validator, we built out the physical infrastructure and we used snarkOps, the tools we developed in-house, to enable us to run a fault-tolerant, highly-available network validator node.

    I’m particularly proud of our validator infrastructure because we are not dependent on any cloud provider. We won’t have to worry about constant fees and we’re not addicted to their services. We are autonomous.

    To become a validator, one has to stake at least ten million Aleo tokens, and since Aleo Foundation holds all the tokens, the only way to get those tokens is to have them delegated to us. All of the other validators, except for the three run by Coinbase, had to have their tokens delegated to them from the Aleo Foundation, too. I believe our contributions demonstrated we are a trusted member of the Aleo community.

    Thankfully, after seeing what our team brings to the table, Aleo agreed to our participation. Aleo delegated the required tokens to our validator address, and we are now one of the core validators of the Aleo community.

    Seeing mainnet launch was amazing. We are grateful to Aleo and all of the other community validators who helped make this a success!

    + , ,

HTTPS://SNOPS.IO

Created by MONADIC.US.