By Drew Beller, Co-Founder of Spanning Labs

Web 3 is a systems engineering problem and it necessitates systems engineers.

When I first started my Web 3 journey, I was frequently told, “smart contract development is like nothing you’ve ever done before; you get one chance to deploy and if you have any bugs you can lose people their livelihoods.”

This was a huge relief to me.

My last few years working on autonomous vehicles were spent leading the cross-functional team that determined what to do around pedestrians. I worked under the assumption that if there was an oversight or a major bug, someone would lose their life, not just their livelihood.

The solution we built was a very complex system of systems with multiple redundant systems of systems. Every time a robot took off on a mission, it had to be bulletproof.

Testing and validating complex safety-critical software isn’t a new problem. Teams building Web 3 applications can draw on decades of experience from engineers who have built technology like rocket ships, airplanes, robots, and self-driving cars.

In fact, many of the challenges in Web 3 relate directly to the skills and experience I’ve gained working on robotics and systems engineering.

Systems and robotics engineering are at its core the studies of distributed compute systems. An autonomous vehicle may have 30+ individual compute systems between sensors and redundant computers. Much like a blockchain, an autonomous vehicle’s many computers have to reach consensus on what action to take, have to do so quickly, and have to do so deterministically.

Once you start looking at safety-critical aspects, you see even more overlap with Web 3. While the compute on an autonomous vehicle is centralized, it is far from trusted because of the extremely high bar set for safety. You don’t have to worry about your computer maliciously sending you the wrong braking force to stop at a crosswalk, but you do have to worry about your computer calculating that force wrong because of a cosmic bit flip or sensor miscalibration.

This high safety bar leads to many of the same problems we see with trustless Web 3 protocols today; thus they have many of the same solutions. Byzantine consensus algorithms were used to verify flight computer calculations long before they were used for mining Bitcoin. Proof of history was being used on autonomous vehicles for deterministic resimulation years before Solana was founded.

From first hand experience, I know systems engineers can jump into the most complex of Web 3 problems and architectures with little to no training. Experience building robust networking infrastructures, autonomous vehicles, rockets, robots, or airplanes is directly applicable to the problems Web 3 faces today.

At Spanning Labs, we are bringing in technology directly from our time building autonomous vehicles. The team’s previous experience in topics like heterogeneous graph theory, feedback controls, temporal logic system design, encoding problems into topology, latent space validation, and resource constrained computing has proven invaluable to building our interoperability solution. In fact, our relayer network (BOS) is based heavily on ROS 2, an open source software designed for decentralized swarm robotics, which is also the basis for most major autonomous vehicle communication systems.

Systems and robotics engineers will help build what comes after Web 2. They are Web 3 engineers. The algorithms they are writing, the mental models they possess, and the ability to design safety-validated systems are all directly applicable to Web 3.

Web 3 doesn’t fully replace Web 2, just as Web 2 before it didn’t fully replace Web 1; rather each generation is a superset of its predecessors. I’m confident that Web 54 will still consist of many static web pages, centralized applications powered by user data, and decentralized ledgers. Thus, the teams building for Web 3 will need to be supersets as well.

Teams will need Web 2 engineers to ensure apps have seamless user experiences, roboticists to design complex state machines, aerospace engineers to create high assurance testing processes, gaming engineers to set up simulation environments, security engineers to protect secret managers, and infrastructure engineers to architect robust services.

There is a need for everyone in Web 3. For Web 3 to reach its full potential, we need to identify and bring in experts from related industries, like autonomous vehicles.

Spanning Labs is looking to build a community where everyone can bring their expertise to the table. For the same reason a Dapp should use multiple blockchains optimized for specific use cases (like Ethereum for high-value asset storage and Avalanche for cheaper computation), a Dapp should optimize their team as well.

If you are a robotics engineer excited by complex state machine design, come build with us.

If you are a frontend engineer driven by delivering the best user experiences, come build with us.

If you are a Web 3 engineer who is obsessed with security, come build with us.

The Spanning Network will be going live with support for a variety of testnets towards the end of this month. We’ll be releasing more documentation over the coming weeks and we are excited to see what innovative projects you build! Let’s make Web 3 spanning.

Website | Docs | Medium | Mirror | Discord | Twitter

Interested in partnering with Spanning Labs in the future to make your team or project multichain? Fill out our partnership form here.

By Drew Beller, Co-Founder of Spanning Labs

Web 3 is a systems engineering problem and it necessitates systems engineers.

When I first started my Web 3 journey, I was frequently told, “smart contract development is like nothing you’ve ever done before; you get one chance to deploy and if you have any bugs you can lose people their livelihoods.”

This was a huge relief to me.

My last few years working on autonomous vehicles were spent leading the cross-functional team that determined what to do around pedestrians. I worked under the assumption that if there was an oversight or a major bug, someone would lose their life, not just their livelihood.

The solution we built was a very complex system of systems with multiple redundant systems of systems. Every time a robot took off on a mission, it had to be bulletproof.

Testing and validating complex safety-critical software isn’t a new problem. Teams building Web 3 applications can draw on decades of experience from engineers who have built technology like rocket ships, airplanes, robots, and self-driving cars.

In fact, many of the challenges in Web 3 relate directly to the skills and experience I’ve gained working on robotics and systems engineering.

Systems and robotics engineering are at its core the studies of distributed compute systems. An autonomous vehicle may have 30+ individual compute systems between sensors and redundant computers. Much like a blockchain, an autonomous vehicle’s many computers have to reach consensus on what action to take, have to do so quickly, and have to do so deterministically.

Once you start looking at safety-critical aspects, you see even more overlap with Web 3. While the compute on an autonomous vehicle is centralized, it is far from trusted because of the extremely high bar set for safety. You don’t have to worry about your computer maliciously sending you the wrong braking force to stop at a crosswalk, but you do have to worry about your computer calculating that force wrong because of a cosmic bit flip or sensor miscalibration.

This high safety bar leads to many of the same problems we see with trustless Web 3 protocols today; thus they have many of the same solutions. Byzantine consensus algorithms were used to verify flight computer calculations long before they were used for mining Bitcoin. Proof of history was being used on autonomous vehicles for deterministic resimulation years before Solana was founded.

From first hand experience, I know systems engineers can jump into the most complex of Web 3 problems and architectures with little to no training. Experience building robust networking infrastructures, autonomous vehicles, rockets, robots, or airplanes is directly applicable to the problems Web 3 faces today.

At Spanning Labs, we are bringing in technology directly from our time building autonomous vehicles. The team’s previous experience in topics like heterogeneous graph theory, feedback controls, temporal logic system design, encoding problems into topology, latent space validation, and resource constrained computing has proven invaluable to building our interoperability solution. In fact, our relayer network (BOS) is based heavily on ROS 2, an open source software designed for decentralized swarm robotics, which is also the basis for most major autonomous vehicle communication systems.

Systems and robotics engineers will help build what comes after Web 2. They are Web 3 engineers. The algorithms they are writing, the mental models they possess, and the ability to design safety-validated systems are all directly applicable to Web 3.

Web 3 doesn’t fully replace Web 2, just as Web 2 before it didn’t fully replace Web 1; rather each generation is a superset of its predecessors. I’m confident that Web 54 will still consist of many static web pages, centralized applications powered by user data, and decentralized ledgers. Thus, the teams building for Web 3 will need to be supersets as well.

Teams will need Web 2 engineers to ensure apps have seamless user experiences, roboticists to design complex state machines, aerospace engineers to create high assurance testing processes, gaming engineers to set up simulation environments, security engineers to protect secret managers, and infrastructure engineers to architect robust services.

There is a need for everyone in Web 3. For Web 3 to reach its full potential, we need to identify and bring in experts from related industries, like autonomous vehicles.

Spanning Labs is looking to build a community where everyone can bring their expertise to the table. For the same reason a Dapp should use multiple blockchains optimized for specific use cases (like Ethereum for high-value asset storage and Avalanche for cheaper computation), a Dapp should optimize their team as well.

If you are a robotics engineer excited by complex state machine design, come build with us.

If you are a frontend engineer driven by delivering the best user experiences, come build with us.

If you are a Web 3 engineer who is obsessed with security, come build with us.

The Spanning Network will be going live with support for a variety of testnets towards the end of this month. We’ll be releasing more documentation over the coming weeks and we are excited to see what innovative projects you build! Let’s make Web 3 spanning.

Website | Docs | Medium | Mirror | Discord | Twitter

Interested in partnering with Spanning Labs in the future to make your team or project multichain? Fill out our partnership form here.