From a technical perspective, this shift marks the official point our hardcoded “genesis” issuance files become obsolete, replaced with a dynamic file that is re-generated from our live UTXO hashmap with each network hard-fork. In the interest of public transparency and to ensure that historical data is available for public scrutiny in the future, we have taken the step as part of our network update of ensuring token issuance files are archived and uploaded to our official Github repository with each reset. The team is continuing to monitor and test the network and integrity of these files as part of our ongoing development efforts, but is pleased to report that so far everything seems to be working perfectly.

In terms of changes that users will notice to the in-browser Saito experience, while our ERC20 token withdrawals continue to be handled manually, we are expecting to update a new application / UI-feature to the Saito Application Suite later this week that will speed up withdrawals by allowing for a greater degree of automation in the token migration process. We are hopeful this will assist us in getting withdrawal times down to about 12 hours from the 24 or so that it currently takes.

On a side-note, we should also mention that we are aware of the publicly-discussed issues with the Anyswap/Multichain ERC20 < – > BEP20 token bridge and recommend/request that users do not attempt to use the bridge until the situation is resolved. In the event of continued problems, we will work to update the aforementioned withdrawal tool to allow BEP20 tokens to be directly burnable and withdrawable to mainnet in a fashion similar to ERC20 tokens, thus avoiding need for the Anyswap bridge completely.

Beyond the changes that token persistence brings to the network and the application suite, there are questions of how it should affect tokenomics questions and what changes – if any – we should be making across the our Dawn of Persistence era. In order to address these questions, and present our own thoughts, the team will be having an update on Saito tokenomics at the end of September that will provide more detailed clarity on how we expect the token persistence curve to look, as well as update to the token distribution schedule to help incentivize on-chain migration as the threshold falls.

On a closing note, we remind readers that the entire crypto space is plagued with scams and to assume by default that anyone who contacts you with claims about migration is a scammer. If you’re not sure what is legitimate, please join the community on our Official Telegram Chat at https://t.me/SaitoIo.

The post Token Persistence Update – September 4, 2023 appeared first on Saito.

The advance is possible in mechanisms where attackers must expend a costly resource (“work”) to participate in consensus. Under these conditions, a malicious majority can be tolerated if the consensus mechanism can asymmetrically strip attackers of “work” over time and restore honest participants to majority status.

Asymmetrically punishing attackers is accomplished by taxing the only activity attackers perform which honest nodes do not: the orphaning of work from other participants. There is a precedent for this type of tax in Bitcoin, but the penalty fails under majoritarian assault. Securing a consensus mechanism beyond that requires making work-orphaning expensive even in situations where attackers produce all of the blocks on the longest-chain.

Framing the problem this way makes it clear why proof-of-work and proof-of-stake blockchains cannot solve it. In those mechanisms, the cost of orphaning work is identical to the cost of proposing blocks once attackers can propose a majority of blocks. When attackers spend resources to push the chain into stasis, the honest network is forced to spend an equivalent amount to resolve the deadlock. Honest nodes face symmetrical losses which prevents their recovering majority status.

The theoretical solution that improves security involves migrating the “work” used to produce blocks into the transactions that constitute them. Attackers may still produce blocks that route around those proposed by honest nodes, but the newly-orphaned transactions can be shifted costlessly into a new block and deposited at the tip of the attacker’s chain to resolve the deadlock. Preventing this requires a more aggressive form of work-orphaning: attackers must move the work-bearing transactions into their own chain. This form of orphaning-by-inclusion is profitable in proof-of-work and proof-of-stake designs but can be made quantifiably costly in others.

Routing work — the addition of cryptographic routing signatures to transactions — is the first known strategy that accomplishes it, modulating down the value of transactions for producing blocks as well as the expected payout from their inclusion. With a sufficiently high per-hop decay (50% or greater) attackers who orphan-by-inclusion face an expected loss from doing so, even if they produce all of the blocks in the blockchain. A properly designed mechanism not only exposes attackers to this cost, but forces them to pay it in a way that reduces their ability to generate work and participate in consensus.

The post Tolerating Malicious Majorities – Advances in Distributed Consensus appeared first on Saito.

A lot of historical work on the ‘Saito application stack’ over time has been experimental and exploratory. We have been pushing the boundaries of peer to peer blockchain applications. This led to a platform with prototypes, unused features and layers of incremental design.

Recent development work has focused on RedSquare and the Saito Arcade in a refactor designed to fix this, resulting in a trimmer, tighter set of functions. Significant changes have been implemented to how cross-module UI elements are created and displayed, and inter-module interactions are easier to program. We have also improved some base level features like transactions are compressed, shrinking them to improve the speed and responsiveness of applications.

For anyone following the overarching project roadmap, our refactoring work is part of our efforts to “dogfood” application development in order to improve the usability of our application suite and development tools, as part of a long-term strategy to increase transaction volume and spearhead broader adoption.

With this refactor largely complete, we are now focused on simplifying and improving the quality of the user-facing experience, such as by adding ‘Web3 login’. This is a simple backup-and-restore option that hides behind a familiar web2 login. This work is accompanied by fixes to identifier management and a visual refresh to the sidebar menu and wallet, creating a much better and more persistent user experience. We are currently stress-testing the login system but believe this kind of “easy wallet restoration” will be key to driving mass adoption of RedSquare and game leagues.

Another feature we have spent considerable time on improving has been peer-to-peer video calls. Team members have moved almost all two-person meetings to Saito Video Chat, and are using our experiences to keep improving stability and usability. Two person calls are currently stable and we are focused on improving automatic reconnection and other features that become critical in group calls. If you are looking for a great way to help, please assist by testing this feature on your mobile devices and report to us if you have any problems.

Ongoing Work

Core work continues to replace the consensus code in our javascript-stack with a WASM implementation compiled from the Rust codebase. This will make in-browser applications faster. In the distant future, WASM (web assembly) will also allow developers to plug applications written in other languages into the Saito web stack.

Our gaming work is focused on improving the leaderboards and adding high-scoring tracking for single-player games. We are sweeping through existing games to improve the UI/UX, and trying to find time for new games including Realms – the open source card-powered enchantment game being driven by community development., We are also making updates to how our digital library module works to provide necessary support for on-chain vintage game and ROM management.

Finally, with the new slide-in wallet moving towards completion we are refactoring 3rd party crypto support to try and improve its reliability and quality. We expect that this will take some time, but expect the result to be much more usable and reliable platform for storing third-party crypto, particularly when combined with the ability to recover accounts with the “web3 login” feature.

As above, we are now regularly posting updates and interacting with community members in Saito RedSquare. This is the best place to stay up to date, participate in the process of identifying and discussing our priorities, and of course experience Saito while you are there.

The post Saito Development Update – March 2023 appeared first on Saito.

1. it is the first “Saito Implementation Proposal” worthy of public discussion
2. it has fascinating implications for core blockchain properties
3. it shows why community engagement matters so much for Saito

The full proposal in is a new Github repository we have created. In the interest of sharing some technical background that might help explain this proposal, let us start this blog post with some background information on how our current codebase handles staking. Essentially, our staking mechanism has the Blockchain (class) create an in-memory data-structure which contains all the UTXO slips that users have deposited for staking. Nodes keep this data-structure in sync and select which participants get paid based on the randomness contained in the golden tickets. Users deposit tokens into this data-structure by sending specially-formatted transactions into the network. They withdraw their tokens using a second type of special transaction.

In this approach, most of the work involved in developing the staking mechanism is writing the code that manages this separate data-structure and inserts and removes UTXO from it. There are many unknowns in this approach largely around performance at scale: what data structures are ideal, how many slips it reasonably includes, what are the performance implications on the speed of block processing when we need to update this staking table when we add a block to the blockchain. These questions are difficult to answer without a large public deployment, which is one reason we have been moving forward with a rollout model that will start with large deposits and gradually reduce the barrier to staking over time.

Over the last three weeks we have been considering an interesting proposal — a suggestion on re-using the existing ATR mechanism to replace these secondary data-structures. We are sharing this proposal first and foremost because we believe it is important and potentially a significant improvement to our existing approach. We also value discussion of Saito Consensus and believe this is worth sharing publicly as it delivers some fascinating properties to Saito almost as an afterthought. Among the benefits:

For more details we encourage everyone to read the full implementation proposal. At the moment, our core team is leaning positive on this proposal and is evaluating it (read: mulling it over). We obviously expect to think about this more before committing any changes to code, but want to share these ideas publicly so that everyone in the community can help digest the ideas. Our experience is that when developers are tasked with implementing features, the default approach tends to embracing complexity. It is usually harder to conceptualize a simple idea than add complexity, but simple ideas often require the most thought.

On a closing note, we are specifically indebted to @brickblockcube for digging into the fundamentals of Saito and — when challenged with a difficult problem as part of a private discussion — thinking through the matter and coming back and provoking us with what is in retrospect a somewhat obvious question, “if we are able to take payments from the ATR transactions looping around the chain, why can’t we issue payments to them as well?” We’re not sure @brickblockcube had this exact mechanism in mind when he asked the question, but we wouldn’t be considering this approach if not for his active engagement.

The post Saito Implementation Proposal #1 – Simplified Staking appeared first on Saito.

To report an issue please email us at bugs@saito.io and let us know roughly what issue you have found. Our team will review your report and determine whether you are describing a critical issue covered under this program. If your report is considered in-scope, we will reply accepting the issue at which point you will be asked for more information, possibly including instructions on how to replicate the problem.

At the moment, our focus is on problems which are able to compromise the user’s in-browser wallet. We plan to expand the scope of this program over time, but at the moment issues that merely cause applications to “break” in reasonably trivial ways will not be considered in-scope.

The post The Saito Bug Bounty Program appeared first on Saito.

The Saito Arcade looks very much like an ordinary website. You can play games, chat, and socialize with friends, so a feature that tells users who else is online makes sense. But the arcade is not an ordinary site. Notice that users don’t login. And, someone can be connected to the Saito Network but not at their computer. Or they can be connected but using a totally different application. 

Making things more complicated, games are not even played “via” the Arcade – they can be played without users even having that application installed. As a bit of historical trivia, it’s interesting to remember that the very first games on the Saito Network were put together before we even had an Arcade module. Invites were sent as messages that users would receive in their email/wallet and click to accept. Games were initialized and played peer to peer (as they still are). We didn’t have card deals then (chess only!), so there was no initialization process and joining games were instant. The only guarantee we have about other Saito users is that they will have a wallet hooked up somewhere at the edge of the network.

Considered this way, the current arcade is less like a walled garden and more like a bulletin board for game invites that provides a UI for configuring invites and handling game initialization. Once browsers are communicating directly, the Arcade can drop away. So while building a liveness widget is one way – but we think there is a better strategy for growth. Namely, instead of turning the Arcade into a destination website where we need users to sit around with an open tab waiting for strangers to show up, we think a better approach is to make it much easier for people to schedule games and share invites socially. Once we have a critical mass of users coming to the Arcade we think that community chat and public game invites will sort out the find-opponent problem.

Before I explain what we are hoping to do here, I want to say that we aren’t opposed at all to someone developing a liveness widget. If you’re a dev and are looking for a reasonably straightforward project to tackle, we would love to work with you on getting this coded and deployed. We’ll provide as much support as is needed to make this application a reality.

With that said, our own team will be more focused on features that don’t require people to be sitting at the Saito Arcade at all. This is why one of the new features that went up last week was the ability for users to create and share game invites as private links. Why not invite a friend by dropping a link in WhatsApp, Telegram or Wechat? The idea is to push the Arcade out into other social spaces. Want to drag someone from Discord into a game? Just send them the link – you won’t even need to explain what Saito is or encourage them to visit the Arcade.

More long-term, we are looking at ways to add support for tournaments and leaderboards and calendars that will let players schedule games in advance. If you want to have a game of Red Imperium after work, why not tweet a link to your gaming calendar and let your friends schedule themselves into your Monday or Friday games? Saito servers can support this process by sending reminder emails or SMS messages. Improving asynchronous game scheduling should also lead to more people being generally available for real-time games.

With that said, there is nothing wrong with a liveness widget. So if anyone is interested in helping us tackle this, we’d be delighted to get  hook you up with a mentor here and show you the ropes. Please send a note to community@saito.tech.

The post Who is on-line on an open platform? appeared first on Saito.

He is 10 and has been learning to code, scratch at school and camp, javascript/html/css with me for a few years. We decided on 五子棋 (Gobang) – five in a row, played on a Go board, as a simple project that could result in a playable game. He had built Towers of Hannoi and Naughts and Crosses (Tic Tac Toe) in javascript before, so this seemed like a good level, and we started with a playable ‘local’ version as step one.

Design meetings were held every morning on the walk to the office and he’d code up parts during the day. It took a little over a week of very non-intensive coding to put the initial version together.

Things I learned along the way.

The game stack is not intuitive for a ten year old. Particularly the first in last out way moves are stacked up then played out took him a while to understand. This isn’t helped by there not being complex moves in such a simple game, so it can be hard to see what it’s for.

Once you have a game that can be played by two players at the same browser, it is very, very simple to move it to the Saito game engine. You need to add a way to record the state of the game (simple if you already had it in a single object) and work out what needs to be sent to opponents as part of each move. Putting this onto the chain and broadcasting it, receiving it and playing out the moves, is… child’s play.

To a kid, maths is more intuitive than nested loops. Set the problem of assigning a row and column value to each cell on the board, the solution was:

Loop through all the cells, and determine the row and column from the ordinal using equations:

           // Set the row as the total divided by the side length rounded up.

           cell.sets.row = Math.ceil(n / x);

           // Set the column as the cell id mod side length.

           cell.sets.col = ((n – 1) % x) + 1;

 Rather than, what I think would be every coder’s instinct: to loop through the rows, and have a nested loop for the columns.

We will probably pretty the game up some, and will definitely take feedback from the community on features and changes, but we’ll have it up, playable in it’s ‘unvarnished’ state for a while.

I have also made an effort to comment up the code as a simple tutorial, something that should explain all the things we bumped into that might help someone building a game on Saito for the first time. These are mostly about handling p2p and the lack of a server.

You can try Wuziqi now on the Saito Arcade.  Enjoy.

The post Wuziqi – Child’s Play appeared first on Saito.

First Impressions

The first thing anyone expecting a cloud deployment and management dashboard will notice is the need to connect up metamask. As soon as you have done that, connected it up and gotten some STACK, it starts to become clear what the guys have accomplished. A proper decentralised hosting option. There is never a need to provide identity, or log in with permissioned credentials. Everything is mediated by signing with your keys via metamask. Everything is paid for via STACK tokens.

How it works

The StackOS dashboard is definitely pretty and is simple enough to use. I had some issues that stemmed from me overthinking things, expecting more complexity than there was.

To get started you need to select CPU, RAM, Storage and Bandwidth allocations, and charge your wallet with enough STACK to pay the monthly fee and sign them over to pay. (Don’t forget you will need gas on the relevant chain in your metamask. This threw me at first, but demonstrated again, that I was in charge here and committing required an on-chain transaction.

The system is container based, load balancing, dns and other tools you’d expect are built in. It will be really interesting to see a community grow around this, and how they start pushing the edges of what the team imagined.

Right now it’s possible to spin up an existing container from the ‘app store’, or pull a public or private one in from the cloud.

I decided to use the standard WordPress container to host a one page website for an up coming Saito community activity. It took a few moments for things to deploy and I was greeted with the WordPress language selection page, filled in the basic data and was in with a new website.

Conclusions

There were some rough edges that the StackOS team helped me with. But experiencing a permissionless version of something I use permissioned every day was really exciting.

We are looking forward to working with StackOS to make various Saito tools available in their app store for simple deployment, and I will be keeping an eye on StackOS offerings as a partner project and as a system administrator.

For more updates, please do follow Saito’s official social media pages:
Twitter: https://twitter.com/SaitoOfficial
Telegram: https://t.me/SaitoIOann
Blog: https://org.saito.tech/blog
Discord: https://discord.com/invite/HjTFh9Tfec
Reddit: https://www.reddit.com/r/SaitoIO/
Youtube: https://www.youtube.com/channel/UCRUhZVAUH4JyWUFmxm5P6dQ

The post Deploying on StackOS appeared first on Saito.

Beyond opening a new frontier in blockchain gaming, the Saito Polkadot Arcade provides a working example of how we believe Polkadot developers should build web3 applications. As visitors can see, Polkadot applications running on Saito offer a better user experience than websites that need external plugins like Metamask, and eliminate the need for centralized infrastructure providers like Infura.

As part of this release, we encourage developers working on Polkadot projects that need in-browser applications to get in touch. We are happy to support the Polkadot ecosystem in getting usable applications running on the Internet today.

While we still have a second milestone to release before the Saito Arcade provides full in-game support for transfers of Polkadot assets, we hope this release gets DOT users and developers excited about what is coming. While we work on delivering our next milestone, we encourage everyone to come and check out all of the open games that already exist on Saito which will be gaining DOT integration shortly: Poker, Chess, Wordblocks, Twilight Struggle, Red Imperium, and many more. 

To make the celebration even better, join our Telegram Channel for news on a series of epic game tournaments & events launching soon which will be open to everyone.

For more updates, please do follow Saito’s official social media pages:
Twitter: https://twitter.com/SaitoOfficial
Telegram: https://t.me/SaitoIOann
Blog: https://org.saito.tech/blog
Discord: https://discord.com/invite/HjTFh9Tfec
Reddit: https://www.reddit.com/r/SaitoIO/
Youtube: https://www.youtube.com/channel/UCRUhZVAUH4JyWUFmxm5P6dQ

The post Saito-Polkadot Arcade is live! appeared first on Saito.

Rather than just provide vague-reassurances that things are going well, in this post I’ll try to go a bit deeper to give more insight into how we are operating and what problems we are dealing with and how we are solving them. And with that in mind, the first thing to mention is that under Clay and Stephen’s leadership tech has gone through an organizational change that is professionalizing our dev environment. We have shifted towards test-driven development and a process of having peer-review on major commits to the codebase. This is pretty standard for larger teams: it has involved changes to how development happens that make it harder for any of us to break things or make arbitrary changes without flagging them with other members of the team first.

In terms of coding focus, Saito Rust has been our #1 priority and we’ve gotten a lot done in the past two sprints. Most of the components in the Saito system have now been implemented in Rust code: block production, storage/retrieval of blocks from disk, mempool management of transactions and blocks, tracking of longest-chain state for blocks in the blockchain, our algorithm for adding blocks to the blockchain, burn fee calculations, signature validation, utxoset management and more. Note that Rust has restrictive policies about memory management and “ownership” so these bits of code are not necessarily working in production. We tend to code and then integrate. The major components we have not tackled in any significant way are network and peer management, automatic transaction rebroadcasting and the staking mechanism.

In general, our development effort has tried to have open-ended development cycles followed by a discussion of what works and doesn’t, followed by focused implementation of the consensus approach into core software. Doing things this way has allowed us to find out: (1) what practical issues we run into implementing the logic in Rust, and (2) what suggestions contributors have on improving Saito. Being open to making changes to the way Saito works has slowed us down because it has meant discussions are about more than just implementing an algorithm that already exists in javascript, but it has also led to some pretty clear wins for which Clay and Stephen deserve almost all of the credit:

• an upgrade to the default hashing algorithm from SHA256 to BLAKE3 that will significantly speed up the overall data-throughput of the network; this is really significant — hashing is the single-biggest bottleneck in the classic Saito implementation.
  
• an optional “pre-validation” step in block-processing that avoids the need for many blocks to even have data inserted into critical blockchain indices until we are sure they are part of a competitive chain; this speeds up work by avoiding the need for it in all but critical cases.
  
• a change to the way that slips are formatted that eliminates the need for lite-wallets to track the blockchain after they have made a transaction: users will be able to spend their change slips as soon as they have created them; there are follow-on benefits that make it easier to spend ATR transactions here as well.
  
• various proposals that effectively shrink the size of Saito transactions considerably when they are saved to disk or sent over the network, including a roughly 40% savings in the size of transaction slips which will allow us to pack more transactions into the same space on the blockchain.

Looking back at the last two months, I think we’ve spent more time exploring various implementation ideas that will not be implemented than I would have expected, but believe the payoff has been worth it in the sense that we are implementing improvements we did not conceptualize as part of this effort. The overall result is that the codebase is probably a bit behind where I expected we would be now in terms of raw features, but it is also cleaner and simpler and development is happening faster than expected too. The hardest part has been sorting out a design process where people can communicate effectively about proposed changes.

In terms of actual development milestones, we’re expecting to finish the classic version of the Saito protocol (no-networking) within 1-2 more weeks. And then tackle peer connections, the ATR mechanism, and then the staking mechanism in turn. This should afford time for testing before live-net deployment.

So what are the numbers on raw scalability? A good place to start is probably this screenshot above, generated by an earlier non-Rust version of Saito I fired up to generate some competitive numbers. What you see here is a test script creating an arbitrary number of fairly mammoth transactions and throwing them into an earlier Saito implementation to check how long it takes for the engine to process them. This is a back-of-the-envelope way to sanity-check our performance by seeing how different kinds of blocks (a few big transactions? masses of small ones?) bring the engine to its knees. This specific screenshot shows a smaller number of data-heavy transactions taking about 2 seconds to process. This is what you should see:

There are three critical bottlenecks that affect our non-Rust implementation: (1) saving blocks to disk, (2) loading blocks from disk, and (3) validating blocks (and transactions). We can’t see the delays in blocks getting saved here because that is happening asynchronously and behind-the-scenes. But we can see that hashing transaction-affixed data and checking those transaction signatures is taking a huge amount of processing time. There are some less obvious lessons too — it is interesting to know that our Google Dense Hashmap is not even breaking a sweat in handling UTXO updates but that our wallet is already starting to struggle, suggesting that core routing nodes shouldn’t even do that work by default.

One of the dirty secrets in the blockchain space is that network speed is the most critical bottleneck for scale. This is one of the reasons the world actually needs Saito, since “routing work” pays for fast network connections and that is ultimately the only way to achieve scale. But the more time we can shave off other work the more time we can afford to waste on network latency, so our focus in terms of core blockchain performance has been on those three critical bottlenecks: (1) saving blocks to disk, (2) loading blocks from disk, and (3) validating blocks (and their transactions).

Without solving any of those issues, what the overall numbers from non-Rust implementations tell us is that any javascript client is going to hit a wall somewhere around 400 MB per minute, and probably sooner if they start getting spammed by malicious nodes. This is useful to know because terabyte-scale requires around 1.5GB per minute so Rust needs to deliver big gains. It is also useful to have raw numbers because while some people think javascript isn’t a performant language this isn’t true — what you see here is *optimized* code that does things like swap-in precompiled C binaries in performance-critical areas like handling the UTXO set.

So how does Rust look right now? In javascript we use JSON and store a lot of data in formats like “human-readable strings” that are slower to read and write from disk. In Rust we are eliminating those and focusing on pure byte-streams to speed-up performance. Most importantly, we are dividing the work of “validating” transactions across the number of CPU cores that a computer has \available. Rust is almost uniquely better suited to parallelization here for some complicated reasons.

And the Rust numbers are much better. In terms of baseline numbers, we are seeing evidence to suggest 2x speed improvements on writing-to-disk and loading-from-disk. The savings here don’t come from the speed of interacting with the hard drive but rather the conversion between the resulting byte-streams and the in-memory objects that can be processed by the software. Saving to disk is not a really critical bottleneck, but loading from disk (or the network) is and so performance gains here are really critical to being able to rapidly validate and forward blocks. Clay in particular has been doing a lot of heavy lifting in pushing us towards better and faster data serialization and deserialization. It’s hard to share hard numbers because serialization work is still underway. We think that 50% improvement in block loading speed is possible.

What about transaction validation? In testing this aspect of system performance, we’ve mostly been dealing with test blocks in the 10 MB to 1 GB range with anywhere from 1000 to 100,000 transactions in total (~300k slips). We don’t really know how much data users will associate with transactions so the differences here are less about approximating reality and more about finding out — given the need to process a metric ton of transactions — how long block validation takes at different transaction sizes. Doing this has helped us learn – for instance – that for most practical transaction sizes a lot more time is spent hashing than verifying the resulting transaction signature. And UTXO validation? That continues to be a cakewalk. Possibly because we are using best-of-breed tools instead of the sort of databases that POS networks drift towards we won’t need to optimize the speed of updating our UTXO hashmap for a long-time.

And the good news here is that Rust is delivering 100% on parallelization. While we can use various techniques to add “parallel processing” to transaction validation in other languages, many require creating multiple “instances” of blocks for separate CPU threads to process individually. Rust is superior for its avoidance of this issue, meaning that once our block is in memory we can throw as many CPUs at transaction validation as needed. For all practical purposes, this makes transaction validation a non-issue. The process still takes a considerable amount of time compared to everything else we are doing, but the performance limit here is the number of CPU threads available, and that is scalable to something like 64-cores TODAY on commercial hardware.

We’re excited to get to the point where benchmarking is becoming realistic and useful. We don’t really want to share numbers broadly on everything quite yet because we haven’t finalized serialization and ATR and routing work obviously have an effect on the performance, but if you are really curious you can always download and run the code and see for yourself. The most important thing for us is that we’ve got a solid foundation for our own team in submitted patches and proposing design changes, and that decisions are being made in terms of actual numbers. Does this make things faster? So we think things are pretty solid.

Our biggest goal for the next 2 weeks is to finish what we consider the classic implementation of Saito. This involves finalizing what versions of algorithms are included by default in the “basic” version and particularly how the mining components interact with block production. After that we will move on with more advanced features (automatic transaction rebroadcasting, staking).

There is lots more to do, but also lots of progress. As always, if you’re interested in checking out what is happening for yourself or joining us and tackling some development, please feel welcome to track or clone our Saito Rust repository on Github. We have a dev channel in Saito Discord where questions and discussions are more than welcome too. Hope to see you there.

The post Saito Tech Update: June 28, 2021 appeared first on Saito.