Does anyone know if there's a simple way of understanding how exactly this speedup works? Standard O(N log N) multiplication uses frequency decomposition via FFT, iiuc; what might this construction look like?
The tldr is that you can turn a single fft into an n dimensional fft, into n 1d ffts and then share a very small amount of the work of the multiple ffts
Something I've been thinking about that I don't quite know how to formalize is the role of _understanding_ in the cycle of progress. The other component would be discovery - generating proofs, creating new algorithms, etc. Discovery pushes the boundaries of a field, but understanding disseminates that knowledge, allowing the field to stand on the shoulders of the new discovery and perhaps make yet another.
Understanding is really the measure of utility. I suspect that an average human's intelligence is similar to one 100 years or even a century ago, and thus our ability to discover new theorems and proofs. The difference is the understanding. We not only have the last thousand years of discovery, but also the compaction, categorization, education, tutorials, etc, that allowed us to learn it effectively in a few years or decades of academia.
AI is accelerating the discovery part, but the _understanding_ part is just as vital for true progress.
Isn't the ability for models to discover new things depend on the model understanding what exists already and figuring out how to apply it? It sounds like we already have everything in place to understand things, prove new things, understand those new things, prove new things with that new understanding, etc.
I'm building a P2P distributed computing mesh that runs in the browser. It's a TS library that provides a few things:
- A WS + WebRTC mesh
- A request/response protocol incentivizing the closest or most efficient peers to respond to requests
- A WASM environment ensuring deterministic execution and supporting contract composition
- Collateralization around responses, ensuring invalid responses have amortized negative value
- A consensus and UTXO layer, focused on low-latency, low-finality micropayments (for request incentive and collateral), using WASM compute as the weight metric
The idea came out of me wondering a few years ago why a multiplayer game couldn't simply be run on the player's machines without a central server. It has grown since, but the focus has remained on low-latency and log(N) state consensus (unlike a blockchain).
It's wrapped up as a single fetch() method, mostly mirroring the browser's native fetch(). There's a lot more I could say; I love working on it and discovering elegant solutions to the problems that pop up. I'm hoping to release a prototype in a few weeks/months. If you're interested in trying it out, let me know (joel at scaffold.io); I'd love to have some other eyes on it.
> The idea came out of me wondering a few years ago why a multiplayer game couldn't simply be run on the player's machines without a central server.
That's how they used to work! Some used peer-to-peer networking, others had one of the players host. Some still let you do this but don't always have networking that "just works".
Yes! That's a great model that works well for trusted participants - I'm attempting to build something that doesn't assume trust in any participant; i.e. empowering a node to trust a computation result from an arbitrary peer.
Sounds like a cool project! Do you have any specific use cases in mind for types of games this would be beneficial for? IMO in most cases having one player be the host is good enough. Maybe competitive games where you want to ensure the host doesn't cheat?
Thank you! My initial impetus was a MMO open-world sandbox game where players could leave/join at will. I was also interested in networking being directly p2p, as opposed to having a server intermediary. The tricky part is maintaining distributed consensus on a shared global state under those conditions, but it's a useful primitive and generalizes to a lot of other applications other than games like forums, social networks, data feeds/pipelines, maybe even chat/messengers (just my hypotheses at this point). It fits well in cases where much of the state is public and shared, as opposed to private data that's more difficult to achieve consensus on its validity.
There's a couple of ways to keep state around but they all come down to who pays the incentive to ensure a block remains available. In the same way as posting verification collateral, a node would accept a liveness incentive and post liveness collateral, then they'd be responsible for serving the data for a period of time or until new state is created.
Who incentivizes the data availability is more of an application-layer question; in this case it could be the game publisher itself or maybe a consortium of players. I've tried to build these options as much as possible into the contract layer as opposed to the scaffold protocol itself.
Pump.co | Backend + frontend engineers | In-person 4 days in San Francisco | $150-200k + equity + benefits
- We save companies money on their cloud spend (AWS and GCP), and are building additional services around security and cost visibility.
- We are profitable and growing extremely quickly ($1m to $10m ARR last year, 500+ customers) and are growing our team to match.
- We're looking for engineers who are passionate about building elegant, scalable products and systems. We are a small team (6 engineers, ~20 total); you will have ownership and will work closely with the business and customers.
Correct me if my understanding is wrong, but there are no crypto transactions involved with arbitrage in the common case. Arbitrage is concerned with the relative price of two assets, for example BTC/USD. There is no bitcoin transferred from exchange A to exchange B, simply the trade of USD to BTC on exchange A and BTC to USD on exchange B.
That is done, but you need a lot of capital due to bitcoin's slow block times. You'll need to have capital on both places to take advantage of the price differential since the price will shift to much by the time you migrate funds from one CEX to another.
But this post isn't about bitcoin, it's about Ethereum. Ethereum is where all the innovation and most of the financial activity occurs. Arbitrage MEV comes from different onchain decentralized exchanges, slippage, defi liquidations, etc.
sandwich bots exploit swap slippage on decentralized exchanges... e.g. a user submits a swap transaction from currency A to currency B with high allowed slippage, a sandwich bot notices and copies that transaction from the public mempool and constructs two swap transactions on either side of it where they swap from A to B before the user and swap from B to A after, profiting from the price move of the user's swap. they submit this as a bundle to MEV-relay with a tip high enough to have it included in a block, and if it's included they book the profit. if not included there's nothing at risk, not even wasted gas. there IS risk if the bundle is exposed to other searchers, which is what happened in this case. multiple bots will often find submit the same bundle with escalating tip amounts, so the profit eventually becomes slim with more participants trying the same sandwiches.
Arbitrage definitely happens in crypto. It’s how prices stay consistent across exchanges. If you have a small decentralized exchange with relatively low liquidity, arbitrage bots come in to capitalize on price discrepancies across exchanges.
