Fetching these models over IPFS would locally cache them and dedupe calls for them by IPFS content ids - https://docs.ipfs.tech/concepts/content-addressing/#:~:text=... which functions similar to a file hash (not an exact parallel, since CIDs represent files that are broken up into chunks).
This would help with object DL deduplication if everyone is using the same models & would also help to decrease centralized data egress costs since with sufficient usage you would be DLing these models from other peers that are running IPFS nodes and holding onto the models.
Mistral-7B is surprisingly decent for general purpose small tasks. The more complex the task or the more specific the knowledge recall, the worse the performance since the smaller the models are - the less breadth they tend to have.
But they're very nice for making PoCs on complex systems since they're near free to run.
1) There wasn't a rollback of the blockchain - the method to fix this was an irregular state change (I.e - at block z, change balance at address x to address y). This was only possible because the nature of the attack left all of the compromised funds locked in place for 30 days. Arguably, if it required a rollback of the blockchain, people probably wouldn't have gone along with it. (Though node operators and miners may still have as evidenced by the bitcoin supply bug and rollback in 2010)
2) The funds in the DAO at the time were roughly 14% of the total supply at the time. This is ~1.5x the amount of ether currently custodied by the largest ether custodians today.
3) The common argument of this event being a slippery slope and that it would lead to frequent recovery of hacked funds has turned out to be false.
4) Since the state change was introduced as a software upgrade, node operators (mining pools & infrastructure providers) all had to opt into the change - which a large majority did. This would indicate that most organizations and individuals were either in favor of this solution or were apathetic to the solution
Was it sticky?