# StarkNet & Cairo significant changes dev. opinionated iew https://github.com/starkware-libs/cairo-lang/releases What's new in Cairo? There have been a lot of changes since the Cairo language has been released. This is a developer opinionated list of the major changes since the 2021-12. StarkWareLtd last releas CairoLang v0.10 (Dec 5, 2022) First release covered: 0.6.2 (12-2021) ## v0.10 (Cairo 1.0) (breaking changes version) **Aug. 29 2022** v0.10.0-pre Pre-release Starknet has its core language modified, it's now a Rusty lang, Starknet foresaw the future of Rust based smart-contract ecosystem ([Luna developers](https://news.coincu.com/90055-fall-of-terra/) and Solana) - End statements with ; - Note that new lines are still part of the language at this point, and you cannot put more than one instruction per line. This will change in Cairo1.0. - Use { … } for code blocks (instead of : and end) - Add () around the condition of if statements - Remove the member keyword in structs - Change comment to use // instead of # - Use ..., ap++ instead of ...; ap++ in low level Cairo code - New transaction version - Nonce are enforced as part of the transaction (bye bye UTXO model) - Invoke execution object with [**\_\_validate__**](https://github.com/OpenZeppelin/cairo-contracts/blob/d12abf335f5c778fd19d6f99e91c099b40865deb/src/openzeppelin/account/presets/EthAccount.cairo#L81) and [**\_\_execute__**](https://github.com/OpenZeppelin/cairo-contracts/blob/d12abf335f5c778fd19d6f99e91c099b40865deb/src/openzeppelin/account/presets/EthAccount.cairo#L127) to differentiate between validation of the transaction (wether or not execution works (TODO: wild guess)) and execution that his pickup by another part of the process in the decentralized system(TODO: confirm) - Declare function to send implementation code for registration - Bridge Layer1 to Layer2 - New **fee** field in [LogMessageToL2 event](https://github.com/starkware-libs/cairo-lang/blob/54d7e92a703b3b5a1e07e9389608178129946efc/src/starkware/starknet/solidity/IStarknetMessagingEvents.sol#L9) when executing L2 contract from L1 - Tx simulation and fee estimation - Support the EC-op builtin. to allows to verify ECDSA signatures - API: Remove entry_point_type field from transaction information ## v0.9.x Fees are now enforced on StarkNet, no more free candy! Contracts must be declared first and then instanciated through the new [deploy syscall](https://starknet.io/docs/hello_starknet/deploying_from_contracts.html#the-deploy-system-call) forcing 2 manual transactions for contracts deployed by EOA. ## v0.8.1 Fees are in now! What's up with that [code](https://github.com/starkware-libs/cairo-lang/blob/4e233516f52477ad158bc81a86ec2760471c1b65/src/starkware/starknet/business_logic/transaction_fee.py) ? See more [here](https://starknet.io/documentation/fee-mechanism/#Introduction). ![](https://i.imgur.com/G2ZidCf.png) - charge_fee ![](https://i.imgur.com/GnKEkFI.png) - calculate_tx_fee_by_cairo_usage ![](https://i.imgur.com/wYIohf7.png) - [L1 -> L2 message cancellation](https://github.com/starkware-libs/cairo-lang/blob/master/src/starkware/starknet/eth/StarknetMessaging.sol) ![](https://i.imgur.com/P4UB8Wm.png) - `version` and `max_fee` are part of the transaction structure now - `__execute__` is now required mandatory entry point for account contract, see more [here](https://github.com/OpenZeppelin/cairo-contracts/blob/main/docs/Account.md#accounts) ![](https://i.imgur.com/gIcuAdK.png) - Added the cryptographic hash function [blake2s](https://en.wikipedia.org/wiki/BLAKE_(hash_function)) to the standard library ### Cairo - Meaningful error messaging(v0.7.0) including local variables and arguments ![](https://i.imgur.com/AwjYaIV.png) - High level memory allocation with the `new` keyword in execution memory segment (whereas `alloc` allocates a new memory segment) ![](https://i.imgur.com/gFPTHzw.png) - Tuples and type aliases, will increase the pythonic vibes of Cairo even further ![](https://i.imgur.com/Ya3bPcE.png) - Fix for python 3.9 ## v0.7.x - [Added a nonce for L1 to L2 message](https://github.com/starkware-libs/cairo-lang/blob/4e233516f52477ad158bc81a86ec2760471c1b65/src/starkware/starknet/services/api/messages.py#L80) this prevents sending the same message twice from the EVM world, e.g: calling a function. ![](https://i.imgur.com/3SPa5Fz.png) ### Addition of EVM compatibilities - events are here ! ![](https://i.imgur.com/rXdCLNc.png) ![](https://i.imgur.com/uOzGLmA.png) (editor's note: TheGraph but for StarkNet please.) - delegate calls prepend delegate_ to external contract function name or `l1_handler` - The `__default__` entry point is introduced, it is similar to the Solidity fallback method as it is executed after missing on the function selector. - The `__l1_default__` entry point same as `__default__` but for in-protocol message from the L1. ### New syscalls - get_block_timestamp() Returns a random number that sometimes appears to grow over time, currently around since 1970-01-01. Notice of deprecation for get_tx_signature(), get_tx_info() is now preferred.
Last changed by  
 
Sylvain Laurent
370

Read more

Untitled

The steps involved in uploading a file are: The user uploads the file to the web application and enters the public keys of the Ethereum addresses of the recipients. The recipients must share their public keys with the user who wants to share the file (5 different public keys is a must for the demo. The reason is, if we are building a ‘private’ file sharing platform also the user who uploads shouldn’t know the real address of the receiver so there is 20% possibility) 2 ) The file is then encrypted with each of the public keys and uploaded to IPFS. (different IPFS files encrypted with different public keys) The IPFS URLs are encrypted with each of the public keys and hashes of the public keys are uploaded to the smart contract. (different IPFS URLs) To access the file, the recipients must follow these steps:

2/10/2023
Untitled

In-chain refers to something that is stored and processed on the blockchain, while on-chain refers to something that is stored on the blockchain but processed off-chain. In the case of NFT artwork, in-chain would refer to the media being processed to its final form by the first execution layer, such as the EVM in Ethereum. On-chain would refer to the media being stored on the blockchain, but the processing and rendering of the artwork happens off-chain using JavaScript, for example, in real-time. Some media formats, such as SVG, contain multiple data streams that may require different levels of processing, it can be rendered using rasterization techniques, but it can also be enhanced with CSS and/or JavaScript. This means that some parts of the image may be processed in-chain, while others may be processed off-chain. Additionally, depending on the context, the final form of the media may be different, it can be a raster image or a interactive vector image, so the processing can be different for each context and each final form. This can make it challenging to determine the appropriate level of in-chain and off-chain processing for certain types of media, and may require careful consideration of the specific requirements and constraints of the use case. Thus we can define in-chain NFT where the artwork does not require* turing complete processing post first on-chain execution (e.g: when tokenURI function return embbed audio/video in metadatas) (as in mandatory). The processing capability being brought by the human user, and therefore, a NFT can be considered in-chain when it does not require post-chain processing, for example, in wallets, twitter profile pictures, and so on. On the other hand, NFTs that require Post-Chain Processing(PCP), for example, in browsers, desktop apps, or games, are considered on-chain NFTs. Example of possible artwork media types with possible Post-Chain Processing:

2/3/2023
Awesome ChatGPT URL list

ChatGPT Bug @Magicking for any inquiries Plan for this document Curate what seems interesting (5/52) <- We are here Curate the document itself to delete duplicate and put in the appropriate category Put that on GitHub (By end of this week)

12/8/2022
Read more from Sylvain Laurent
Published on HackMD