Fabric cryptography

Esp ef

What if, we had static commitment on dynamic and updatable data


For this we need new type of tree or commitment

#research
#todo

Advantage of fraud proof against validity proof

Solving fraud proof withdrawal delay with provable proof of burn

But we need some sort of commitment for sequencer to put burn tx on the block if pushed block get challenged and failed during a fraud proofing flow

به یه چیزی نیاز داریم که سیکوئنسر کامیت کنهکه تحتهذ شرایط اگهمجبور شد یک block لایه دو آی دیگه رو جایگزین یکی دیگه کنه حتما همون تراکنش های خاص برداشت رو توش قرار بده و به این commit کنه

Unlocking the lookup singularity with Lasso


https://eprint.iacr.org/2023/1216

chinese hashing algorithm 😄
https://www.ncbi.nlm.nih.gov/pmc/articles/PMC9414062/pdf/sensors-22-05951.pdf

https://people.cs.georgetown.edu/jthaler/ProofsArgsAndZK.html

Proofs, Arguments, and Zero-Knowledge

https://ethglobal.com/showcase/lit-tornado-9wokg

A mixer without ZK

Imagine we have a custom factory contract. This contract has a method that takes a salt as input and deploys a contract using create2. The logic of the deployed contract includes a self-destruct method.

Now, the question is: Can we deploy a contract with the same address as the destructed contract by using the same salt in the factory?

#question
#research

Consider the scenario where the answer is affirmative. Given the existence of TStore and TRead opcodes, what potential use cases can arise?

Is it possible to generate a temporary contract that remains valid for just a single transaction?

( In my thoughts I think we should adapt the T opcode mindset for the create2 opcode too)

Report on USDT Phishing on Polygon network:

The attacker's strategy was based on obtaining approval for a contract address that hadn't been deployed yet.

Here's a step-by-step breakdown:

1- The attacker used a phishing technique to gain approval on the Tether (USDT) token.
2- They then invoked the Factory Contract to deploy a contract on the approved address.
3- Finally, they executed a function from the newly deployed child contract to transfer the USDT tokens.

The attacker utilized a vanity address for the External Owned Account (EOA) and the Contract to decrease gas costs. However, they transferred the stolen assets to a non-vanity address to avoid the risks associated with vanity addresses.

The core concept behind this attack was the use of Create2 and the ability to predict a contract address, thereby luring the user into granting approval on a contract that hasn't been deployed yet.

Users indeed have the option to verify the address they're planning to grant approval to on a blockchain explorer.

No legitimate decentralized finance (DeFi) application should ever ask you to give approval to an External Owned Account (EOA).

As a regular user, you should NEVER grant approval to unverified contracts. Always ensure that the contract you're interacting with is verified and trustworthy.

#dapp
#phising

During This Investigation for a friend i saw weird approach on the polygon for charging user for the gas cost

https://polygonscan.com/address/0x0000000000000000000000000000000000001010#code

every polygon transaction contain event from this contract, because the polygon has pre-deployed contract on this address for Matic Token and in every transaction people pay their fee buy using the token transfer in polygon

feeTransfer

but this contract is pre-deployed contract and transferring through it doesn't make extra charge on the fee.

they call it MRC20 standard

https://www.reddit.com/r/0xPolygon/comments/sfx4o2/matic_as_a_mrc20_token_versus_just_matic_on_the/

Combining Merkle Mountain Ranges with Validium 🤔

#reserach

HackMD?

https://hackmd.io/@aztec-network