NeuronPool

Selling a liquid 1 ICP 8 Year Neuron: app.sneeddao.com/sneedex_off… Starting bid: 0.01 ICP

For those of you mystified by what you see in the animation in @dominic_w's post, it is a visualization of $SNEED DAO's resource flow. You can see it live on the DAO's 100% on-chain web dApp, here: app.sneeddao.com/rll_info Built in partnership with @anvil_ic Neutrinite DAO and @NeuronPool, it uses $NTN "Vectors" in combination with our own, custom built canisters, to automate the DAO's token flows. With a Neuron Vector from @NeuronPool we collect maturity from Sneed DAO's 8 year $ICP neuron. We distribute that, as well as $SNEED and $ICP revenue from any of the DAO's other projects, using Splitter Vectors from NTN to targets controllable by the DAO. We use some of the ICP to buy back $SNEED from the market using NTN Buyback vectors, we burn some, and finally we distribute portions of this flow to DAO members via Sneed DAO's custom Rewards Distribution canister. NTN Vectors are in my opinion one of the coolest techs available on $ICP and soon anyone will be able to use them to compose their own automated resource flows when the ability for Caffeine.ai to integrate with external canister APIs is turned on. As a side note, I can't help musing that when I built that live diagram in Dom's post, I thought it was pretty cool, and I sure dreamed that Dom would see it one day!😁 Snassy's dreams:✅

Some people say $ICP is not a real blockchain at all. It depends on what you think is implied by the word "blockchain". I think many people think it implies a monolithic, eternal ledger. The ledger should record every system event such that current system state can be restored by replaying the events in order. It has to be eternal, so you can arrive at current state by starting from the first event, and it has to be monolithic so all system events are captured and the replayed state becomes complete. These are excellent qualities for a token transaction log. But it doesn't scale to an application layer. The ICP token ledger shares the qualities described above, and so do (most of) the ICRC1 tokens on ICP. Tokens have monolithic ledgers with all transactions from genesis faithfully recorded. But the complete state of the Internet Computer does not share the same qualities. The state change histories for the "canister" smart contracts are ephemeral - every mutation is not stored forever in an eternal ledger. And nobody stores the complete state of all subnets in a mega-ledger somewhere, state is spread out into different subnets. In short, you can't replay the Internet Computer from genesis to arrive at today. The conclusion is clear: ICP supports creating traditional blockchains on top of it, but is itself not a traditional blockchain. So if ICP (the application platform) is not a traditional blockchain (though ICP the token is), then what is it? It is an application platform that is based on blockchain technology. A subnet, which is where ICP smart contract canisters are hosted, consists of a number of nodes. Nodes are redundant machines that all run your canister smart contract code in parallel and then use blockchain consensus technology to ensure they arrive at the same results. Because nodes are run by independent operators, your smart contract runs on a limited but decentralized blockchain in the subnet. But because this blockchain has a lot of state (your entire application) with a lot of changes, this blockchain quickly grows very large. So node operators are allowed to throw away old history after a while. This means you can't replay a subnet from its genesis to arrive at current state. You can't verify the entire blockchain history. But that would be an unrealistic goal for a blockchain hosting whole applications. Laxing that requirement is the right approach for a blockchain based application platform. You still get a long list of benefits that remain by using blockchain consensus to replicate application state between independent node operators, such as code being tamperproof and verifiable, you get robustness and uptime, deterministic execution, deployment is permissionless as you'd expect, transactional integrity is built in, and more. What Vitalik captures in his "trilemma" is that a monolithic, eternal blockchain can't capture the state of an on-chain application layer. For this reason, the central tension in web3 application architecture has consistently been: How do we combine on-chain with off-chain? There have been several answers. Zero Knowledge proofs is one such solution. L2 networks that settle to L1 networks is another. Chainlink is such a solution, that uses decentralization and game theory to give similar properties to off-chain computing as we see with on-chain computing (deterministic, reliable, unstoppable, etc). ICP represents another answer to this tension: It relaxes some of the constraints associated with traditional blockchain ledgers, namely eternal persistence of all events in one monolithic ledger. By strategically using remaining components from blockchain technology to decentralize the off-chain application layer, it gives it most of the same properties as are associated with traditional on-chain computing, only that it scales. ICP creates an application layer that can scale, integrates well with traditional blockchain ledgers and extends them with an off-chain application layer that is actually also on-chain, albeit with a slightly different interpretation of "blockchain" from the traditional, eternal, monolithic one. In my view it represents the best approach to complementing traditional, eternal, monolith ledgers with an on-chain application layer that can scale, with the correct trade-offs that retain the maximum amount of beneficial blockchain properties in the application layer. It stands to reason you can't keep all of every application's state history in an eternal ledger, and it makes sense you can't cram all applications into one common ledger. Web3 means your whole application is decentralized. That means some of it lives in eternal, monolithic ledgers. Some of it lives in off-chain but still decentralized systems like Chainlink. Some of it live in decentralized, non-eternal, sharded blockchains like ICP. This is why I consider ICP the on-chain solution to the decentralized off-chain application layer. It's as on-chain as the application layer will get, and it complements Chainlink very well on how to host the parts of your web3 application that don't fit on a traditional, eternal, monolithic ledger, but that should still be decentralized.

Excellent post from @Exalted_Grey breaking down what $NTC from #NeutriniteDAO is all about!

I am a huge Enhanced Orthogonal Persistence (EOP) fan. EOP from @dfinity is a feature of ICP that makes persistence transparent and upgrading deployed canisters safe from data corruption. @dominic_w is right to be very proud of it. However, EOP seems to currently be in an "in-between state" that makes it almost unusable. Before EOP, if you removed a "stable" (persistent) variable in your code, or changed its type, you would get a warning during deployment that the data in your deleted/modified variable would be lost. This was pretty much perfect, because you very often wanted to indeed drop that old data, and when you didn't the warning prevented you from data loss. Now, instead, with the current iteration of EOP, when you remove or change the type of a stable var, the deployment will warn you that you would lose data, and then just refuse to deploy. Your only option now, unless you want to litter your code base with unused old variables, is to entirely wipe the canister of all its data to proceed with deployment. This is a terrible state of affairs! I constantly lose way more data than before (wiping everything) and I am wasting hours on deployment issues (where I jump back and forth between versions of my code, and I now have to create branches for old versions that include all the new stable vars that have been deployed by newer versions - good luck teaching Caffeine users how to do this!) where everything used to just be easy. It is turning ICP from a low-friction development experience into a high-friction one! @dfinity - I beg you, please hurry up and add back the option to drop the state for dropped/changed variables! This is sucking all the fun and productivity from my ICP dev experience, and I can't imagine Caffeine users will have any idea why their apps get stuck in a state where they can't deploy new code.