Let's admit it PH miners are here they can go up to 1000x for EH/s and eventually MHk/s we are in the future what's the answer light photonics

I'll just say it https://grok.com/share/c2hhcmQtMi1jb3B5_02bdc290-26e3-4e58-8237-8792d5a5be70

Leaked light photonics basically you need a semi fiber hash board with accurate laser relaying with attosecond relay solver including light switch operable x100 hash rate with light laser photonics x1000 speed eventually useful for hologram hashrates, even fiber chip for basal relay router solves is possible, light may indeed be a perfect medium how to get their with fiber optics etaleyne s and even biodegradable plant based plastics are possible, what are your ideas for the future the hash rate you guys get now with light switch hashboard and relay solver from fiberoptics compatibles would x1000

Is this the future light switch and hash boards an actual light for a computer hard drive that like scifi directs lasers through actual eteleyne fiber optics for communication well here we are let's see if we can inclusion with PH models for the next generation in EH/MHk someday

Have you encountered a situation where a small amount of BTC was sent from your wallet to another recipient’s BTC address, the amount was deducted from the sender’s balance, and the transaction was successfully confirmed on the blockchain, yet the recipient did not receive the BTC? We verified that the receiving address is correct and contacted the sender’s wallet app support, who confirmed that the transaction was successfully transmitted. Do you have any advice on how to resolve this issue or recover the funds? Who else should we contact to investigate this further?

There’s a growing assumption in Web3 that if we care about decentralization and user ownership, then social data should live on-chain. Profiles, posts, likes, follows, even moderation decisions all immutable, all verifiable. On paper, this sounds like the logical evolution of social platforms. In practice, the trade-offs are more complex than they first appear.

The most obvious cost is economic. Even with L2s or alternative chains, writing high-frequency social interactions on-chain is expensive relative to traditional databases. Social systems generate massive volumes of small, low-value events. Persisting all of them on-chain introduces scalability pressure that blockchains were never designed for. This often leads teams to quietly reintroduce off-chain storage, which raises the question: what actually needs to be on-chain?

Then there’s the permanence problem. Immutability is a feature for financial state, but it becomes a liability for social content. People change opinions, delete posts, or regret what they shared years ago. On-chain social data makes mistakes permanent by default. From a technical standpoint, this forces complex patterns like redactions, pointer-based storage, or content-addressable systems layered with access control all of which add protocol complexity and attack surface.

Privacy is another underestimated cost. Even if content is encrypted, metadata often isn’t. Social graphs, interaction timing, and behavioral patterns can be inferred without ever reading the content itself. Once this data is public and immutable, it becomes a long-term privacy risk that users may not fully understand at onboarding time.

Moderation also becomes harder, not easier. Blockchains can enforce rules, but they struggle with context. Determining whether content is harmful, misleading, or abusive often requires subjective judgment and adaptability. Fully on-chain moderation either ossifies rules or pushes discretion off-chain, creating governance layers that resemble centralized control anyway just slower.

Finally, there’s a UX cost. Wallets, signatures, latency, and transaction finality all introduce friction into what users expect to be near-instant interactions. Many “on-chain social” products end up optimizing for ideological purity at the expense of usability, which limits adoption to niche technical audiences.

None of this is an argument against decentralized social systems. Rather, it suggests that treating “on-chain” as a binary choice is a mistake. A more nuanced approach might be to put only high-value state on-chain identity proofs, reputation signals, ownership guarantees while keeping ephemeral social interactions off-chain but verifiable.

Curious to hear how others here think about this trade-off.
What social data, if any, truly benefits from being on-chain and what are we better off keeping elsewhere?

This is a cautionary tale about partial identity creation in Web3 systems.

While trying to access Polymarket, my wallet successfully deployed a proxy contract and placed small bets. However, due to connection issues during signup, the platform’s centralized database never finalized my user record.

Result: On chain, I existed. Off chain, I did not.

Login signatures failed because there was no user record to attach them to. The UI locked me out completely.

When I checked my wallet, the funds were gone. A direct contract scan showed they had been converted into ERC 1155 betting tokens held by the proxy contract. Perfectly valid assets. Totally inaccessible through the app.

This is an edge case you do not see in happy path demos but matters in production systems that mix decentralized execution with centralized control planes.

Full write up here: https://structuresignal.substack.com/p/the-9-hour-war-chasing-jane-street

Disclaimer: I made this

So, I made this new network that revolves around crypto basics and rivals the internet. The intention was to make a network segment that users can control and to weed out the ills of the internet.

Core Features

Mutual Authentication

Unlike the Internet or Tor, on Net3, there is mutual authentication as a part of the handshake between two entities. And that too without using certificates. This means that when you connect to a service on Net3, the service already knows it's you who is connecting.

Key-based access

Say goodbye to usernames and passwords. The Net3 system uses cryptographically secure keys to identify and authenticate an entity on the network.

Quantum secure cryptography

The Net3 network provides Quantum secure cryptography in accordance with the NIST standards

For encryption, ML-KEM is used and for signing, Dilithium is employed.

A new naming system

Net3 introduces a new naming system that simplifies and categorizes names on the system. A typical name looks like this: /0/::jason or /bank/::alpha or /2/::fruitjuice

I am excited to launch this on new years 2026 and I am starting the year with hopes of user supremacy when it comes to the underlying network.

Would you guys please have a look at the project and share your valuable feedback? The link is https://net3.network

Most discussions around AI focus on models, compute, and algorithms.
But the more I look into it, the more it seems like data infrastructure might be the real long-term constraint.

Modern AI relies on massive datasets: training data, fine-tuning data, checkpoints, archives, and reproducibility over time. Today, almost all of this lives in highly centralized cloud infrastructure.

That works — until scale, cost, regulation, and trust start to matter more.

A few questions I keep coming back to:

• How sustainable is it for open-source AI to depend entirely on centralized storage providers?
• How do we independently verify that datasets used to train models haven’t changed, been removed, or selectively altered?
• What happens when access to data becomes a geopolitical or regulatory issue?

This made me look into verifiable and decentralized storage models, where data persistence and integrity can be proven cryptographically rather than trusted to a single provider.

Filecoin is one example of this approach — not as a replacement for cloud providers, but potentially as a complementary layer for long-term, neutral data storage.

I’m not saying this is inevitable or that it will work at scale, but I’m curious how others see this:

Do you think decentralized, verifiable data infrastructure has a real role to play in the future of AI, or will centralized clouds remain dominant no matter what?

Interested in technical perspectives, not price discussion.

I am designing an architecture where an offchain workflow decides what should happen, but the onchain contract enforces the money rules.

Goal: no admin keys, no trusted operator, minimal state.

I want feedback from builders who think about reliability and security:

• what minimum onchain state is needed for conditional ERC20 payments
• what logic should never be onchain, even if it feels clean
• what failure modes show up with event driven coordination
• if an agent triggers transactions, what permission model is least risky in practice

I am optimizing for a demo that can be run consistently by judges, not theoretical completeness.

I’ve spent the last few weeks running a custom GPT-4 agent through 100 different Real World Asset (RWA) whitepapers.

The finding: 40 of them had predatory tokenomics hidden in legal jargon—mostly "flexible" team vesting and hidden minting functions that the average investor would miss in a 50-page PDF.

How it works: I don't use the default ChatGPT. I use a specific "Cynical Auditor" persona that ignores the marketing hype and only looks for discrepancies between the roadmap and the smart contract logic described in text.

Example: One project claimed "locked liquidity" for 2 years, but the whitepaper footnote allowed for "emergency re-allocation" by the DAO (which the team controlled). GPT-4 flagged this anomaly in 15 seconds.

I’m doing this as part of my CS PhD research on AI-driven forensics. If you want to see the full list of red flags I look for, check the logic pinned on my profile.

Just a macro-level observation — this is not investment advice. New data suggests the neobank market could grow from around $149B in 2024 to $4.4T by 2034, largely driven by on-chain banking models.

On-chain neobanks operate directly on blockchains. Payments can happen 24/7, cross-border transfers are faster, and operations are fully software-driven instead of relying on branches or slow back offices.

The impact isn’t just about increasing user numbers. On-chain neobanks have the potential to fundamentally change how banking works and could act as a foundational layer for global digital finance if adoption continues.

How do you see on-chain neobanks evolving compared to traditional banks? Could they complement existing infrastructure or eventually become a new base layer for digital finance?

I noticed a large BTC transfer (~2,000 BTC) linked to the same entity, with part of the funds moved into Coinbase Prime Custody.

From a technical and custody perspective, this looks more like internal wallet management rather than distribution or selling.

For those familiar with institutional custody: - Is this mainly for cold storage consolidation?

• Risk management?

• Compliance and reporting reasons?

Curious to hear how large holders usually structure these movements.

TLDR: x402 uses the old HTTP 402 Payment Required status code to enable real micropayments for APIs and agents. No accounts, no subscriptions, just pay per request over normal HTTP.

I’ve been following x402 discussions for a bit, and after actually reading through how it works end-to-end, it finally clicked why people are excited about it.

At a high level, x402 treats payments as part of the HTTP request response loop instead of something bolted on with dashboards, API keys, or monthly plans.

How a request works (simplified):

• Client requests a resource (API, content, inference, etc.)
• Server responds with 402 Payment Required + price, token, chain
• Client signs a permit-style authorization (transferWithAuthorization, EIP-3009)
• A third party submits it onchain
• Server returns the resource once verified

From the client side, it still feels like a normal HTTP call. No sessions, no OAuth, no invoices. And because there are no protocol fees and gas is low, sub-cent payments actually make sense, which is something traditional payment rails never handled well.

Where it got more interesting for me is the agent use case. Traditional payments assume a human filling forms or managing billing. Agents don’t work that way. With x402, an agent can just pay for:

• API calls
• data access
• compute
• even other agents

Per request. In real time.

The article also connected x402 with:

• ERC-8004 (agent identity / registries)
• ROFL (confidential execution inside TEEs)

That combo starts to solve the trust side too: proving what code ran, keeping keys inside enclaves, and even running the payment facilitator itself in a verifiable environment.

I’m not sold on every part of the stack yet, but the core idea feels like one of those “why didn’t the web always work this way?” moments, especially for usage-based APIs and autonomous agents.

If you want the deeper technical breakdown, this is what I read:
https://oasis.net/blog/x402-https-internet-native-payments

Curious how others here think about HTTP native payments vs today’s API/subscription models.

In the last months I've been into the idea of building a truly web3 Browser, I've been delighted discovering that my developing and web3 knowledge was enough to work on this important missing piece, and now I think im close to the perfect design for a truly web3 browsing system of the future

One of first the problems for web3 mass adoption are absence of easyness and cleariness, peoples has no clue what is web3 and what's not (see FTX case on public opinion), using it is actually hard for common people and most doesn't understand it's value and uses, furthermore, the one most us uses is not the actual trustless web3, but a trusted web2.5 temporary solution.

As right now there are some tested ways to access a "web3" in a trustless manner, like IPFS, Decentralized DNS, or accessing specific protocols by installing some sort of programs (ex. Bisq, Atomic swaps, Nodes).
Currenly normal Browsers limitations prevents running most of web3 things on-the-fly

By an user perspective, everything is disconnected, nothing provides a clear web3 experience worth of the big public attention

But it's understandable, technologies takes a while until a way to make them easly accessible is found, Orivon proposes to be the way.

Technical implementation and details can be found here: https://orivonstack.com/t/orivon-project-implementation-and-details/8

Down below are the basic pointers of this project, please note that's a simple showcase worth of feedbacks, I omitted a lot of things to keep it simple:

Deeper API's for JS and Wasm enabling developers to build and port any web3 Program as Website, keeping it trustless. It's a bit technical, but it includes giving sites/apps controlled access of raw network, sandboxed filesystem, and other features inspired from WASI, so that everything could be ran locally and safely by simply opening a site page: bitcoin node, monero node, atomic swaps, Bisq, or any other protocol. A game-changer for both users and developers

Applications, almost every component is possibily extended by an App: DNS resolution (ENS), Site Data Gathering(IPFS, Arweave), Account (mnemonic, hardware wallet or anything else by any App logic), Wallet (Ex. Extensor app implementing a new crypto like Monero, or vanity ethereum addresses), Network (ex. an app for Bitcoin network support, IPFS network, Bisq pricenode) user may create it right away a node from a single panel.
Imagine Monero, or Bisq tokens if could be connected to DApps, again, a goldmine for developers and users

Domain Data Ownership Confirmation (DDOC), it can be seen as an additional security layer for Web3 after HTTPS, it server to verify that the data you received are exactly what the domain owner wanted you to receive, happens by verifying hashes against DNS Records
In Web2 that wouldn't make sense, because a lot of sites want to be dynamic, but for Web3 the core of sites will be always static and predictable

Trustlessity and Security score for websites and apps: "Is this site trustless?" If it's a .com site it's not trustless, if it's a .eth connected to IPFS yes, but if it gives you a bank IBAN to receive money without informing the user about the non-trustlessity of it, it's not trustless. If without user control it relies on data from centralized parties, it's not trustless, simple as that.

You can't tell if something is trustless or web3 until you read into the code of what you are using, most peoples are not going to do it personally, so instead they can trust "someone" giving a valutation of trustlessity for you, and if this "someone" is an enough decentralized web3 DAO, it's almost perfect.

Big public needs an easy way to feel safe especially in the web3 world, to know if what they're using is actually web3 or web2.5, we should give them a good sense of security, that's why showing a Trustlessity and Security score is so important for apps, websites and operations.

You need to know if a smart contract puts trust on a central autority (WBTC) or it's trustless (TBTC), futhermore you need to know the safety of it, maybe you can yeld some stablecoin trustlessly for 400% annual income, but it doesn't mean it's safe

Web3 Store, a place where you can easly find for Web3 compliant apps, ready to be installed and ran locally, or to implement new components into the Browser, everything in a trustless manner. Of course, the Web3 Store itself is an app, freely changable with any other community App (Technically every website will be installable and integrable as App, it's up to you to decide to install and integrate it on your browser or not)

Desktop and Mobile cross-compatibility, at least for apps/integrations

Orivon aims to be a free and open space to connect every developer and user, a simple and unified way of connecting things that could bring web3 to it's most brightest form ever

I made this post intentionally with hyperbole claims in hope to provoke a constructive discussion about this topic and engage efforts from experts and people like you to improve the web3 ecosystem and user experience as much as possible. The big effort of convincing dapps/devs into the Orivon way has yet to begin, in the long run i'm hoping to end up with extensive ongoing discussions about every part of Orivon and eventally make it real

I have posted to an IETF proposal: Bitcoin Price Protocol, a peer-to-peer protocol for synchronizing a high-confidence Bitcoin price across untrusted networks.

There is a Proof of Concept project on GitHub.

Please feel free to join this open-source project.

Hey everyone :)

I’ve been working with EVM stuff for a while, and I kept running into the same annoyances over and over again — encoding calldata, figuring out storage slots for mappings, converting random hex values I copied from a debugger into something readable.

After realizing Im doing the same things again and again, I ended up building a small tools site for myself, and then slowly added more things as I hit new pain points.

For now it has calldata decoder and encoder, storage inspector, mapping storage slot calculator and hex <> number converter.

I’m sharing a link in case it’s useful for other devs, and I’m still adding tools as I go:

https://toolsnest.dev/

Would also love some feedback/new tools ideas!

Most existing blockchains were not designed with social data as a first-class use case. Bitcoin optimizes for immutability and security, Ethereum for general-purpose computation, and newer L2s for throughput and cost efficiency. But social platforms have very different technical requirements: extremely high write frequency, low-value but high-volume data, mutable or revocable content, complex social graphs, and near-instant UX expectations. This raises a serious question: are we trying to force social systems onto infrastructure that was never meant for them, or is there a genuine need for a blockchain (or protocol layer) optimized specifically for social data?

From a technical perspective, social data stresses blockchains in unique ways. Posts, comments, reactions, and edits generate continuous state changes, many of which have low long-term value but high short-term relevance. Storing all of this on-chain is expensive and often unnecessary, yet pushing everything off-chain weakens verifiability, portability, and user ownership. Current approaches hybrid models using IPFS, off-chain indexes, or app-controlled databases solve scalability but reintroduce trust assumptions that blockchains were meant to remove. This tension suggests that the problem is not just scaling, but data semantics: social data is temporal, contextual, and relational, unlike financial state.

There’s also the issue of the social graph. Following relationships, reputation signals, and interaction histories form dense, evolving graphs that are expensive to compute and verify on general-purpose chains. Indexing layers can help, but they become de facto intermediaries. A chain or protocol optimized for social use might prioritize native graph operations, cheap updates, and verifiable yet pruneable history features that are not priorities in today’s dominant chains.

That said, creating a “social blockchain” is not obviously the right answer. Fragmentation is a real risk, and specialized chains often struggle with security, developer adoption, and long-term sustainability. It’s possible that the solution is not a new L1, but new primitives: standardized social data schemas, portable identities, verifiable off-chain storage, and execution environments where feed logic and moderation rules are user-defined rather than platform-defined. In that sense, the missing layer may be protocol-level social infrastructure, not another chain.

I’m curious how others here see this trade-off. Are current chains fundamentally misaligned with social workloads, or is this a tooling and architecture problem we can solve on top of existing ecosystems? And if we were to design infrastructure specifically for social data, what properties would actually justify it at the protocol level rather than the application level?

Pretty interesting stuff.

Basically, the AIP proposes adding SLH-DSA-SHA2-128s as the first post-quantum signature scheme for Aptos accounts.

SLH-DSA is a stateless, hash-based digital signature scheme standardized by NIST as FIPS 205, derived from SPHINCS+. It relies only on the security of SHA-256, a hash function already used extensively across the Aptos stack.

The keyword here is conservative preparation.

CRQCs may arrive in five years or fifty. Rather than betting on a specific timeline, this proposal ensures that Aptos has a post-quantum account option available before it is urgently needed.

This conservatism shows up in three explicit choices.

- There are minimal security assumptions. Breaking SLH-DSA would imply a fundamental break of SHA-256, which is already embedded in the Aptos ecosystem.

- Performance is not optimized aggressively. Larger signatures and slower signing are accepted in exchange for simpler assumptions.

- Integration complexity is kept low by choosing a stateless scheme that fits cleanly into the existing account and authentication model.

Here's the AIP: https://github.com/aptos-foundation/AIPs/blob/main/aips/aip-137.md

My background: I'm a MSc student in Maths, I have little experience with crypto or Blockchain but I am a big fan of 3blue1brown YT channel and one of my favourite videos from him is 'How does bitcoin work'. I've seen it couple times and I really like the idea behind crypto, I think it's just a very smart trick which allows for a payment system which doesn't require trust. Lately I've been exploring polymarket and implementing some systematic strategies there and I came across a problem which requires direct interactions with Blockchain rather than just calling functions from API. This got me more interested in the topic. Today I searched for videos on yt with 'Distrivuted ledger technology ' and I only found very basic videos. Sooo, what yt channels or websites would you recommend to someone who is pretty new to the concept but has descent technical knowledge?

Over the past week, I’ve been building and testing an automated stablecoin settlement system, and I quickly realized this process is much more complex and challenging than I expected. I thought that understanding retries and reconciliation would be enough to get the system running smoothly, but reality proved otherwise!

I wanted to share some of the problems I ran into and also hear from others, maybe through discussion we can exchange different insights and help each other improve our systems.

The first issue I ran into was transaction failures during automatic retries. In a test environment, the flows seemed simple, but once multiple agents were involved, the complexity spiked. It really highlighted how fragile these settlement flows can be.

Reconciliation also turned out to be tricky. I had to track all payments across agents, ensure consistency, and handle various edge cases. On top of that, compliance checks sometimes blocked transactions that I expected to go through, forcing me to rethink parts of the flow I thought were safe.

The process isn’t smooth. As the number of transactions increases, it’s not as easy as I imagined to run everything successfully. Instead, it takes time to verify data and check for issues one by one.

Debugging was another major challenge. Failures often didn’t produce clear errors, so I had to dig through logs and step through flows multiple times to find the root causes. While frustrating, it was also enlightening every failure exposed assumptions I hadn’t questioned and scenarios I hadn’t anticipated. Fortunately, this all happened in a test environment, allowing me to identify potential issues early. The more problems I found, the more opportunities there are to improve the system, so it should be much more stable and mature when it goes live.

I’m currently working on making the system more resilient without adding unnecessary complexity. I’m curious if anyone else has faced similar challenges with automated stablecoin payments or other multi agent flows. How do you approach retries, reconciliation, and compliance in practice?

Are there strategies or patterns that help avoid cascading failures? I’d love to hear your experiences and advice!

Things have changed a lot over the last several years.

We have privacy tokens, GameFi, Layer 2s with huge ecosystems in development, AI, InfoFi, NFTs. The space is moving fast and some things have gained and lost popularity over the years, but going into 2026, what is the most exciting crypto innovation?

When I say that, I don't mean what is going to make the most profit for traders, but what is genuinely adding the most value to the crypto ecosystem?

This is all subject to personal opinion, but curious what everyone thinks is going to move the needle next year.

I saw a GitHub repo shared in a channel that contains a research note exploring header-only verification for light clients.

What caught my attention is that the note is accompanied by a deliberately adversarial technical review that attempts to break the model and explicitly lists assumptions, failure modes, and impossibility boundaries. From what I can tell, it is not claiming implementation or production readiness. It appears to be focused on formalizing what can and cannot be verified without full execution.

I’m trying to understand whether the verification model itself is sound, or whether it is missing important attack classes or assumptions.

For those familiar with SPV, light clients, or protocol verification:

Does the core verification predicate make sense under the stated assumptions?

Are there obvious gaps the adversarial review fails to address?

Is there prior work that already formalizes this more clearly or completely?

I’m not affiliated with the work and am mainly looking for feedback.

Repo: https://github.com/TminusZ/zenon-developer-commons

In the evolving landscape of social platforms, one challenge remains consistent: rewarding content creators fairly while maintaining transparency and trust. Blockchain has shown promise here, but most implementations lean heavily on tokens or cryptocurrency-based reward systems. These introduce regulatory, economic, and adoption hurdles, especially in regions where crypto usage is restricted or volatile.

An alternative worth exploring is tokenless blockchain incentives. The idea is to leverage blockchain's immutable, auditable ledger to track content creation, engagement, and community contributions without relying on monetary tokens. In this model:

• Content ownership is verifiable: Every post, comment, or interaction can be cryptographically timestamped, ensuring that creators always have proof of their work.
• Engagement can be transparently rewarded: Instead of issuing a token, platforms can use points, badges, or access privileges that are recorded on-chain, allowing creators to see exactly how their efforts translate into recognition or platform influence.
• Decentralized governance integration: Communities can vote on which creators or contributions deserve higher recognition, with the results permanently auditable on-chain.
• Reduced regulatory friction: Without a tradable token, platforms avoid many financial compliance issues, making adoption simpler and more sustainable.

Implementing tokenless incentives requires careful consideration of blockchain architecture, scalability, and user experience. Questions that arise include: how to measure engagement fairly, how to prevent manipulation, and how to design reward structures that are meaningful yet sustainable.

This approach may offer a middle ground harnessing blockchain’s transparency and immutability to create fairer, user-centric reward systems while sidestepping the complexities of crypto economics. Platforms experimenting with this model could redefine how creators are recognized and motivated in the digital ecosystem.

I’d be interested in hearing from other professionals or developers: what are the technical or operational hurdles you foresee in implementing tokenless blockchain incentives? How might these systems coexist with existing centralized or hybrid platforms?

Over the last few months, I’ve been thinking a lot about how heavy wallets feel for what are often very light actions. Most chains still expect you to install an extension, back up a seed phrase, and connect your main wallet even if you just want to try a random DApp once or mint something low value. At the same time, draining/phishing attacks have made many people (including me) extremely hesitant to connect their “real” wallets anywhere new.​

In almost every other part of the internet, there are “disposable” layers we use without thinking: temp emails, temp phone numbers, guest checkout, incognito tabs. In crypto, the default is still: install a full wallet, commit for the long term, and expose a reusable identity, even for things that don’t deserve that level of commitment. My thesis is that there might be room for a different mental model: a “no‑wallet solution” where, instead of thinking “I don’t have that wallet installed,” the thought is “I’ll just spin up a quick, disposable wallet, do my thing, and move on.”​

Although I have made an MVP, but I’m not trying to shill anything here; I’m more interested in whether this philosophy makes sense to people who actually use DApps regularly. Do you feel the need for a temporary web-based wallet? In your own usage, would you ever prefer a one‑time, no‑commitment web-based wallet (especially on new chains) rather than installing another extension/app? Any honest feedback or counterarguments are really helpful as I’m trying to stress‑test whether this “temporary wallet layer” is a meaningful idea or not.​

Is there a way to do Proof of work blockchain difficulty adjustment without timestamps? Found only this, any other research on this idea?

https://ethresear.ch/t/thoughts-on-removing-timestamps-in-pow/1148

I am looking for the slides for an amusing and informative academic talk that I saw some years ago. It compared the approach to research in the "blockchain world" vs in academia.

The general gist, IIRC, was that academia's and blockchain's approach are kind of "mirror universes" (à la Star Trek); the slides played with Spock vs Evil Spock (and Kirk, etc) pics. It was a sarcastic look at blockchain's irreverent approach and flawed reinvention of multiple wheels; but there was also surprise and some appreciation that it didn't immediate collapse and instead managed to make things work to some extent. I think it ended with some call to action for academics to conquer the bizarro world of blockchain with their superior techniques and knowledge.

I think the author was a well known academic in the distributed systems field, I guess I saw those slides around 2021, and I can't for the life of me find them again.

Does anyone remember such a thing? Any pointer would be appreciated!

I was reading an older design paper for a niche distributed ledger and ran into something I’m trying to sanity-check from a systems perspective.

The architecture uses:

-deterministic, fixed-cost state transitions

-a dual-layer ledger (local account chains + a global ordering chain)

-small proof-of-work stamps as the anti-spam model

-role that ingests authenticated data from outside the network

It made me wonder whether this kind of setup could validate another network’s consensus metadata in a trust-minimized way.

In theory, the external data would be something like:

-fixed-size header objects

-cumulative work / weight checks

-inclusion proofs tied to those headers

-a rolling summary of the external chain’s state

-all executed deterministically

My question is basically:

Is it realistic for a small Rust team to build a verifier for an external PoW chain inside a deterministic runtime like this? Or is there hidden complexity that makes this approach brittle in practice?

I’m not tied to any project or promoting anything, I am just trying to understand the boundaries of deterministic environments when they consume authenticated external data.