The Sia Foundation Roadmap

This Sia roadmap provides mid to high level insight into core Sia development. It will be updated once a quarter at minimum, and will show an outline of what we’re currently working on, why we’re working on it, and what we have in mind after that’s done.

Our primary development goal for 2024 is to launch the “v2” hardfork. “v2” is our codename for a massive overhaul to Sia’s consensus mechanisms. It will modernize Sia’s core consensus code and provide a number of usability, performance, and quality-of-life improvements to the network.

After the hardfork, we will be working on reducing onboarding friction for users, developers, and enterprises including:

  • Light worker agents for renterd to increase horizontal scalability for enterprises, but also enable users to download and upload objects from all of their devices.
  • Simple SDKs for developers to interact with the Sia network directly.
  • A mobile and web app that lets all users take advantage of the cost savings, privacy, accessibility, and performance advantages of decentralized storage without the hassle of buying crypto or managing storage contracts.

“v2” is an umbrella term that refers to an upcoming radical overhaul of Sia’s consensus code. The primary change is the transition from a large, unwieldy database of UTXOs to a compact cryptographic accumulator, bringing myriad benefits to performance, scalability, and functionality. This is a big deal: it requires changing the block and transaction formats, which have been untouched since Sia’s mainnet launch back in 2014. As such, we are taking this opportunity to clean up a few other warts in Sia’s consensus code, giving the project a solid foundation for many years to come. For a more technical dive on how Utreexo works, check out Luke’s blog post here and MIT Bitcoin talk here.

  • UTreexo
    • Near instant syncing
    • Reduced blockchain size
  • Improved UTXO spend policies
    • “Composable” unlock conditions
    • HTLC support for atomic swaps
  • Storage contract changes
    • Early contract termination
    • Collateral efficient renewals

August 2024

  • Reset Anagami testnet - Complete

November 2024

  • Upgrade Zen testnet

December 2024

  • Release v2.0 ready software
  • Announce activation dates

RHP4, short for renter-host protocol 4, is the next iteration of the protocol hosts and renters use to communicate. Our goal for RHP4 is to increase the parallelism of data uploads, reduce protocol overhead, and improve download performance. A new protocol is required to enable some exciting new features to be available after the Utreexo hardfork, such as early contract termination, capacity reservation, and contract renewal fund rollover. RHP4 will also enable storage consumers to download and upload data directly in the browser without installing additional software.

  • Improved upload and download performance
  • Concurrent uploads
  • Decentralized uploads and downloads in a browser without downloading software

October 2024

  • Implement RHP4 client in coreutils - In Progress

December 2024

  • Release Sia SDK beta - In Progress

The new Sia renter, replacing the current siad renter module. Drawing on what we’ve learned from siad, skyd, and us, we designed renterd from the ground up to be modular and horizontally scalable. Although the average user likely won’t notice, a renterd deployment is actually a set of interconnected services. As such, it can distribute workloads in parallel across multiple machines, and can be configured to store its metadata in any SQL backend. This flexibilty makes renterd easier to integrate with other Sia ecosystem software, such as Sia Satellite and S5, and addresses the scalability barriers that have historically hampered enterprise solutions.

August 2024

  • Price pinning for gouging settings - Complete

October 2024

  • Add support for RHP4 - In Progress

November 2024

  • Release hardfork ready v2.0.0 alpha

December 2024

  • Release hardfork ready v2.0.0

The new Sia host, replacing the current siad host module. The host module has been chronically neglected for years, and suffers from poor upload performance, data integrity issues, and a general lack of user-friendliness. hostd is our greenfield reimagining of the Sia hosting experience, bringing a sorely-needed refresh to our host community. Aside from addressing performance bottlenecks, hostd also -offers superior metrics and monitoring tools, which will allow users to make informed decisions about storage allocations, contract parameters, pricing, and quality of service.

October 2024

  • Add support for RHP4 - In Progress
  • Release hardfork ready v2.0.0 alpha

December 2024

  • Release hardfork ready v2.0.0

The new Sia wallet, replacing the current siad wallet module. walletd aims to be the go-to option for average holders, lite wallet developers, exchanges and miners that need a secure place to store their SC. Accordingly, it supports both hot and cold setups, including multi-sig schemes and hardware wallet integration. Like renterd and hostd, walletd comes packaged with a sleek, yet powerful UI, which can be securely accessed from any device.

Note: you do not need walletd to be a renter or a host; renterd and hostd include their own built-in hot wallets.

September 2024

  • Improve support for exchanges - Complete

December 2024

  • Release hardfork ready v1.0.0

The new Sia explorer, replacing and going far beyond the current siad explorer capabilities. explored will serve as both a standalone blockchain explorer with a web interface, and as a library providing powerful indexing and searching capabilities to third-party explorers (e.g. SiaStats) and “lite-client” systems like narwal. explored will be developed and launched alongside the Utreexo overhaul, making it one of the world’s first Utreexo-native block explorers.

October 2024

  • Beta release

December 2024

  • Release hardfork ready v1.0.0
Document version date: Oct 24, 2024
Jan 19, 2025
  • Fixed an issue where the global files view was not showing full file paths.
Jan 19, 2025
  • This PR refactors out uploadManager as a distinct context, it was previously part of the files context. Originally this made sense but as the features have evolved it became convoluted. With all the other changes we now have four clear contexts related to files and uploads: filesManager, files, uploadsManager, and uploads.
Jan 19, 2025
  • The uploads list now has two views, one for local uploads only and one for all uploads including from other devices.
  • This improves the UX but was also just necessary for the UX to make sense since we no longer immediately create multi part uploads with the daemon for queued uploads (changed in https://github.com/SiaFoundation/web/pull/880), so the uploads list fetched from the daemon was no longer could be relied on as a exhaustive list of all uploads.

Screenshot 2025-01-16 at 10.52.38 AM.png

Jan 19, 2025
  • The application no longer lags when uploading thousands of files.
  • The performance was improved with the following two changes:
    • The uploads state map which can store thousands of records and receive hundreds of progress updates per second was moved to ref-based mutable state.
    • Multipart uploads are now created when they are popped off the queue and start uploading, previously adding a directory with thousands of files would immediately create a multpart upload session for every file.
Jan 19, 2025
Jan 19, 2025
Jan 19, 2025
  • Updated test suites to pass with the changes introduced in #873
Jan 19, 2025

Signing v2 transactions has a slightly different flow and structure from V1.

  1. Build the transaction
  2. Calculate the input sig hash
  3. Sign the input sighash for each siacoin and siafund input using its private key
const state, network; // should be retrieved from the API

const txn = {
    "siacoinInputs": [
      {
        "parent": {
          "id": "a2b01527c128eebd19056d5048d6b18b31df1fa9589993c55d50607dc097e69c",
          "stateElement": {
            "leafIndex": 4646,
            "merkleProof": [
              "aac548e6cdd2f05daa89ce83b1935bb1f2d4b363a1d27ed3158f8157d209eea7",
              "211e336ba260f72dbe8059e7e564414cda75386ebaf79720ee1078e6aa513e15",
              "3ad4326fae446f729679cdb80fd1ea55c184c025bf228cd4cf49471be9c517f6"
            ]
          },
          "siacoinOutput": {
            "value": "424999930000000000000000000000",
            "address": "2b8fc779876872055333fa0609f37a604be076e97bfeeab4d1c7df7d02f9cff3b8e6317047fa"
          },
          "maturityHeight": 0
        }
      }
    ],
    "siacoinOutputs": [
      {
        "value": "15000000000000000000000000000",
        "address": "2e5716a6ba598292b2c0233fcc9e21f992c5f536ae1e0634907855224d5e9216a0c1256e0085"
      },
      {
        "value": "409999918000000000000000000000",
        "address": "2b8fc779876872055333fa0609f37a604be076e97bfeeab4d1c7df7d02f9cff3b8e6317047fa"
      }
    ],
    "minerFee": "12000000000000000000000"
  },
  sigHash = wallet.v2TransactionInputSigHash(state, network, txn);

txn.siacoinInputs.forEach((input) => {
    const privateKey = getPrivateKeyForAddress(input.parent.siacoinOutput.address),
      unlockCondtions = getUnlockConditionsForAddress(input.parent.siacoinOutput.address); // I can't remember if you store this as the policy or unlock conditions on the address or in the local storage

    input.satisfiedPolicy = {
      "policy": {
        "type": "uc",
        "policy": unlockCondtions
      },
      "signatures": [
        wallet.signHash(privateKey, sigHash)
      ]
    };
});

txn.siafundInputs.forEach((input) => {
  const privateKey = getPrivateKeyForAddress(input.parent.siacoinOutput.address),
    unlockCondtions = getUnlockConditionsForAddress(input.parent.siacoinOutput.address);

  input.satisfiedPolicy = {
    "policy": {
      "type": "uc",
      "policy": unlockCondtions
    },
    "signatures": [
      wallet.signHash(privateKey, sigHash)
    ]
  };
});

/*
{
  "siacoinInputs": [
    {
      "parent": {
        "id": "a2b01527c128eebd19056d5048d6b18b31df1fa9589993c55d50607dc097e69c",
        "stateElement": {
          "leafIndex": 4646,
          "merkleProof": [
            "aac548e6cdd2f05daa89ce83b1935bb1f2d4b363a1d27ed3158f8157d209eea7",
            "211e336ba260f72dbe8059e7e564414cda75386ebaf79720ee1078e6aa513e15",
            "3ad4326fae446f729679cdb80fd1ea55c184c025bf228cd4cf49471be9c517f6"
          ]
        },
        "siacoinOutput": {
          "value": "424999930000000000000000000000",
          "address": "2b8fc779876872055333fa0609f37a604be076e97bfeeab4d1c7df7d02f9cff3b8e6317047fa"
        },
        "maturityHeight": 0
      },
      "satisfiedPolicy": {
        "policy": {
          "type": "uc",
          "policy": {
            "timelock": 0,
            "publicKeys": [
              "ed25519:9dd50ac053764d67b6bcee937a1186c7d3341daedd326f6022afca8c4021d6bb"
            ],
            "signaturesRequired": 1
          }
        },
        "signatures": [
          "c21ac65cd105460879dfdaa37cf7efabf42e7978f85c7e1fe73f95c4637b3e0b64dd43f052a9f59194abfc0ba678d4c9e9122a821c9a7a5b45c4c204e8d2470d"
        ]
      }
    }
  ],
  "siacoinOutputs": [
    {
      "value": "15000000000000000000000000000",
      "address": "2e5716a6ba598292b2c0233fcc9e21f992c5f536ae1e0634907855224d5e9216a0c1256e0085"
    },
    {
      "value": "409999918000000000000000000000",
      "address": "2b8fc779876872055333fa0609f37a604be076e97bfeeab4d1c7df7d02f9cff3b8e6317047fa"
    }
  ],
  "minerFee": "12000000000000000000000"
}
*/

I'm hoping you'll be able to use this API to construct the transaction instead of using /fund and /fundsf separately: https://github.com/SiaFoundation/walletd/pull/211

The request body is the Siacoin and Siafund recipients. The response is an unsigned transaction.

Jan 18, 2025

If only we had an api package 🤔

Jan 18, 2025

This PR was created automatically. Merging it will create a new release for 0.9.1

  • Fix account JSON encoding
View full activity feed →