<p​reland:monero.social> If this 1. Ensures a semi-constant sized blockchain, and 2. Can be implemented without getting in the way of FCMP++#2.0(idk what the most up-to-date acronym for fcmp is lol)

<p​reland:monero.social> Then I’d be very interested in this becoming implemented

<p​reland:monero.social> It would open the door in many ways for how my “universe” concept could be implemented, as there is currently a lot of it blocked by the size and time-scaling inherent to the current blockchain

<s​trawberry:monero.social> No need for multiple chains if you can have just 1 in constant size

<s​trawberry:monero.social> Is that actually possible?

<h​ardhatter:monero.social> If there’s enough desire for it and if for some reason the most prominent monero researchers can’t figure out an implementation in a reasonable amount of time (I think they can do it), I could probably develop a constant sized zk blockchain if the blockchain size problem starts becoming a obstacle. This doesn’t seem that difficult conceptually and I’ve solved similar types<clipped message>

<h​ardhatter:monero.social> of problems effectively encoding updatable proofs that retain the proof of prior updates in a constant space for non-cryptographic applications.

<s​trawberry:monero.social> Doesn't that give us instant sync for practically unlimited TPS? Of course there's desire for that, what's the catch?

m​onerobull i just got hired at cake

<d​ave.jp:matrix.org> Congrats 🥂

<k​ayabanerve:matrix.org> The Solana execution architecture doesn't immediately benefit Monero. All transactions need a global order in the tree where Solana's VM focuses on scaling nonconflicting sections.

<h​ardhatter:monero.social> Besides dealing with the compatibility of implementations of other features in monero’s design, possibly needing reimplementation for them to be compatible.

<h​ardhatter:monero.social> The catch is people have to store their own transaction history. And also wallet recovery by mnemonic phrase alone is out the window. It’s a pretty large design change and there might be more implications not coming to mind rn

<k​ayabanerve:matrix.org> ZK rollups remove execution, not size of the transactions themselves (though our TXs are considered large due to their ZK proofs, and further ZK proofs could replace those, allowing them to be erased).

<k​ayabanerve:matrix.org> You fundamentally don't get a constant sized blockchain with all state. Mina solves this by deleting old data from their standard nodes. That has the side effect of you needing someone with an archive node (so their standard nodes are basically light nodes).

<k​ayabanerve:matrix.org> They do have a constant sized validity proof though.

<h​ardhatter:monero.social> I think if we are going to make use of direct compression we should expect users to compress their own transaction history at their own discretion while standard nodes just store the constant sized validity proof.

<h​ardhatter:monero.social> And that buys people more time to figure out better compression algorithms before they’ll practically need one given the storage space people generally have access to today

<h​ardhatter:monero.social> Imo while it may not be the first priority, making monero nodes able to run on very weak hardware is something I really think should be an objective. Without that it’s gonna be a very long time before hardly anyone can realistically use monero on home manufactured processors and storage devices

lza_menace: congrats

I hope that it works out well for you

<3​21bob321:monero.social> Do you get free cake also ?

<k​orgprivacy:matrix.org> 📰Missed Monerotopia Episode (#179)? Check out the Price, NEWS, GUEST Segment.

<k​orgprivacy:matrix.org> Reports here! ⤵️

<k​orgprivacy:matrix.org> Price Report:

<k​orgprivacy:matrix.org> Youtube: youtu.be/pOxrxQ4uBTg

<k​orgprivacy:matrix.org> ODYSEE:

<k​orgprivacy:matrix.org> odysee.com/@MoneroTalk:8/xmr-ups-its-stablecoin-game-08-17-24:f

<k​orgprivacy:matrix.org> News Segment:

<k​orgprivacy:matrix.org> Youtube: youtu.be/VB2Salb4ofY

<k​orgprivacy:matrix.org> ODYSEE: odysee.com/@MoneroTalk:8/forbes-says-no-one-used-xmr%2C-stamping:5

<k​orgprivacy:matrix.org> GUEST Segment:

<k​orgprivacy:matrix.org> Youtube: youtu.be/VaUhAfEiTbg

<s​pirobel:kernal.eu> if you want to learn about smart contracts, study solana. I learned anchor recently. what matters is the state size, not the ledger size. (the size of the program code, and accounts state vs the whole blockchain history) This whole scaling debate is completely obsolete since we got recursive zero knowledge proofs x.com/spirobel/status/1653540777698676736 (it is not just m<clipped message>

<s​pirobel:kernal.eu> e saying this ... tromp (inventor of cuckoo cycle, grin contributor) mentioned this in the monero subreddit

<s​pirobel:kernal.eu> so scaling is mostly about network bandwidth and compute+memory if you want to have smart contracts (which practically you have to have, because otherwise there is no dex -> which means more centralization, choke point if the government decides to put pressure on cex / otc traders to delist)

<s​pirobel:kernal.eu> this sums it up well. In solana they talk about it in the terms "state vs ledger" with state being the transactions + information (programs, accounts) that is necessary to evaluate if a transaction is valid or not and ledger being the transaction history

<s​pirobel:kernal.eu> the whole debate is to some degree orthogonal to zk stuff. it is just because for historical reasons people are obsessed with having the whole transaction history available on the active nodes of the network, even if that is strictly not necessary to evaluate if a new transaction is valid or not.

<s​pirobel:kernal.eu> there could be some real benefit for zk proofs to verify monero pow on light client. But we would have to dig into this if it is feasible and what the benefit is exactly (for me the biggest potential is that we could have smart contracts verify monero transaction history in the context of another blockchain in a trustless way, which would enable new kinds of DEX stuff / interoperability)

<k​ayabanerve:matrix.org> You can't compress beyond entropy and the on-chain ZK proofs are at entropy hardhatter.

<k​ayabanerve:matrix.org> I disagree ledger vs state is the important distinction here. Not only because I believe ledger is valuable, yet because Monero doesn't have state reductions. Every meaningful item on the ledger (every output) becomes a static entry in our state forever.

<k​ayabanerve:matrix.org> There are items not meaningful (the existing ZK proofs we can recurse out).

<k​ayabanerve:matrix.org> The minimal output size is... 64 bytes and the associated wallet data? So is that 97 or 129 bytes right now?

<k​ayabanerve:matrix.org> While you can even prune out the wallet data, then the issue is no one can scan their wallet data and you've added a liveness assumption to receiving.

<k​ayabanerve:matrix.org> *can scan their historical outputs

<k​ayabanerve:matrix.org> I'm not saying that degree of minimization isn't worth pursuing via ZK proofs. I'm just noting it isn't ledger pruning.

<k​ayabanerve:matrix.org> (Or at least, what I'd consider ledger pruning as per this discussion with the provided examples)