In in the second paragraph of Casper the Friendly Finality Gadget there is a double use the word 'and' -

There are two major schools of thought in PoS design. The first, chain-based proof of stake[1, 2], mimics proof of work mechanics and features a chain of blocks and and simulates mining by pseudorandomly assigning the right to create new blocks to stakeholders. This includes Peercoin[3], Blackcoin[4], and Iddo Bentov’s work[5].

First line in casperTFG paper section 1.1 omits a citation to pbft. Probably it could be this paper.

http://pmg.csail.mit.edu/papers/osdi99.pdf

Does it make sense to only apply the utility reduction penalty to non preparers/non commiters? It appears that if a validator has submitted a validation message they should be pulled out of this penalty.

https://github.com/ethereum/research/blob/master/papers/casper-basics/casper_basics.pdf

The requirement that all money deposited by validators is destroyed if two PREPARES are published is wrong and needs to be modified.

Indeed, in case of an unintentional software bug not even in the node software, but in the underlying
operating system, such as Linux, a large proportion of validators (a deposit-weighted majority in the language of the paper) may lose their deposit in case of an automated OS upgrade, which can lead to multi-billion $ losses.

It will also create a multi-billion dollar incentive to hack the underlying operating system.

First steps:

• 'management' category on ethresear.ch
• awesome-open-management list
• transparent Foundation

I want to be part of ETH research foundation for one topic on pure research and applied research.

Please , let me know or point me any docs to get started.

I don't know if this is the appropriate place to highlight this issue, but I have experienced an address collision after setting up a new computer with Parity.

I've mentioned the details here, https://ethereum.stackexchange.com/questions/16347/ethereum-address-collision . But this seems like something fairly major. I am completely open to answer any questions.

Hello,
I am new to the cryptography and blockchain world. I am implementing verkle tree, its proof generation and verification. For this purpose I need to import the blst library to use BLS12_381 elliptic curve. I did git clone blst but i am unable to install it in my ubuntu system and getting error during cmake installation. Could you please tell me how can I install blst library for python, or if there are any other libraries that performs the same functionality as blst supported in python?

It might be possible to use zkSNARKs for verifying computations of neural networks quite efficiently. The reason is that a single multiplication gate might suffice to model a neuron if the activation function of the neuron is a rational function. This means that the number of gates will be quite small. We still have the problem that the number of wires is extremely large. The scheme by Groth (On the Size of Pairing-based Non-interactive Arguments) trades complexity in the number of multiplication gates for the number of wires, so that might be feasible (and the Groth scheme can be implemented with the planned precompiles).

If the weights of a neural network are public, it is quite easy to fool it (you analyze the network like you do in backpropagation). On the other hand, there are also use-cases where the weights are private. In this use-case, there would be a fixed SNARK for a universal neural network of a fixed size and topology (all of them sharing the trusted setup). The weights would be part of the private input. If you do not do anything else, the prover can prove anything about the input. Because of that, the universal neural network also has a component that computes a hash of the weights which is part of the input. That way, the input selects a neural network by the hash of its weights. The prover can now evaluate the neural network and create a zkSNARK showing that it computes a certain result.

There are not too many rational activation functions and in the general circuit model of zkSNARKs, a polynomial would not be a good fit as e.g. y = x^3 does not have a large slope at x=0. Here, we have to think of zkSNARKs less in the circuit model but rather in the "set of polynomial equations" model: The function y^3 = x is already quite close to the arc targent or some other step function and can be realized with only two constraints or "gates". Another activation function is the "bent identity": y = (sqrt(x^2 + 1) - 1) / 2 + x - this one can be realized with just a single gate.

Would this be a good repository to create a curated list of papers relevant to ongoing research in Ethereum?

Issue

• I think there is an active discussion on the liveness property of "CBC Casper the Friendly Ghost".
• "CBC Casper the Friendly Ghost" may only reach consensus in exponential many steps
• even if CBC reaches a consensus, it is hard for a participant to decide whether a consensus has been reached.

Proposed Implementation

In this paper https://github.com/yonggewang/BFT-Protocol-XP , we discuss several revisions of "CBC Casper the Friendly Ghost". We hope to hear community comments on this and will be happy get more discussion. thanks!

This issue refers to the bitwise LMD Ghost implementation:
https://github.com/ethereum/research/blob/master/ghost/ghost.py

In the event a chain has two children of equal weight and the log lookup is successful, the implementation calls get_clear_winner(). This will choose a winner based on the ordering of the python dictionary (in contrast to the bitwise selection which breaks ties based on lowest hash of the block). See line:

Should this perhaps be > rather than >= as it seems that a clear winner is not obvious for equally weighted children.

1.3
The footnote in para. 1 for correct-by-construction process does not refer to an actual paper. Either give a proper citation for the paper, or if it hasn’t been published yet, say so, and don’t cite it.

What is the behavior of the contract when a contract call runs out of gas. What happens when you send ether to a DELEGATECALL forwarder in the hope to buy some digital asset but do not send enough gas? Does the forwarder throw or does it keep the ETH without transferring the asset?

Not a python programmer myself so I had to revere engineer the bytecode:

https://github.com/JonnyLatte/MiscSolidity/blob/master/forwardFactory.sol

Maybe my implementation is faulty in which case disregard this issue however for my implementation I have a forwarder contract that behaves badly:

With enough gas: (works fine, delivers token and change)

https://kovan.etherscan.io/tx/0x792939b51d759e81a0eba0dcca80dda3ea86aa4449fdcd146bb2bec4f79f4fb8

Without enough gas:

https://kovan.etherscan.io/tx/0xbefe597e6511c8861a96638d6db9190478899be73e74c1dbbcd4f2cbc3f19374

Steals buyer funds and does not deliver token.

1.3
The footnote in para. 1 for correct-by-construction process does not refer to an actual paper. Either give a proper citation for the paper, or if it hasn’t been published yet, say so, and don’t cite it.

it would be great Readme file has brief information about this repository

I was reading this article: https://medium.com/@VitalikButerin/exploring-elliptic-curve-pairings-c73c1864e627

(good to know that math I studied found a real use case :)

The article contains a link to https://github.com/ethereum/research/blob/master/zksnark/bn128_field_elements.py which now is missing.

Found the script here https://github.com/ethereum/py_pairing/blob/master/py_ecc/bn128/bn128_field_elements.py

I could add an empty bn128_field_elements.py with a comment if it makes sense.

According to latest version of the Casper FFG paper ;

The penalty for violating a rule is a validator’s entire deposit. This maximal penalty is the defense against violating the protocol.

However, according to a few discussions on https://ethresear.ch/ and some of the talks I attended to, it seems like the partial slashing scheme will be adopted.

In figures 1 and 2, it says there are dotted lines, but the lines in the figures look unbroken.

https://github.com/ethereum/research/blob/master/papers/CasperTFG/CasperTFG.pdf

Upload the latest file, or better still have it automatically create the PDF and include it, so it will stay up-to-date with each commit.

As mentioned in the cbc-casper gitter, there seems to be a little typo in the CasperTFG paper on line 504:

"The score, remember, is used to by the GHOST fork choice rule to choose between children of some block."

Direct link:
https://github.com/ethereum/research/blob/master/papers/CasperTFG/CasperTFG.tex#L504

PS. The paper was great, love your work!

The problem:

Programmers make mistakes and cause bugs which can affect large sums of money (In centralized systems it’s relatively easy to take a rollback decision and the damage is diminished)

The risk:

People will lose faith in Ethereum when more cases like Parity’s loss of 500k Ether will occur (They’ll be afraid of losing their money when trusted services make such huge mistakes)

The solution:

Enabling a secure hook in a smart contract which will redirect execution to a substitute smart contract which will get activated when the following conditions are met:
The contract owner has activated the hook
The community has consensus on the substitute smart contract presented by the contract owner

• Though a fork will be needed to add this mechanism to the system, No fork is needed when requesting to activate a hook. If at least 51% of the community votes for the substitute contract, it is added to the chain, and the replaced contract redirects to the substitute

• This solution still doesn’t solve the case when someone else is able to take ownership of the contract, but it could solve many other critical bugs cases.

#36

Please put a hypertarget and hyperlink for some symbols. For instance, when I read the epsilon symbol for 2.11, I had to scroll back up (to 2.5) to remind myself what that was. With hyperrefs I could click the ref, read the target, and scroll back to where I was or use CTRL+F. Similarly, hypertargets and hyperlinks for “dependency”, “later”, “latest messages”, and “validator weights” on p. 7, 3.1, would be helpful for a refresher, particularly the latest message. Also for the helper function. Alternatively or additionally as @MicahZoltu suggested just have more meaningful variable names. Looking at other literature, the convention is to use single character variables. So just use hypertargets and hyperrefs, if anything, unless you want to break with convention.

I am reading the note on data availability, which states:

Even if succinct zero knowledge proofs can be used to verify correctness, an attacker getting away with publishing invalid blocks

If a SNARK/STARK can verify correctness of a block, how can an attacker get away with publishing an invalid block? What is the difference between correctness and validity? The two parts of the sentence above seem contradictory.

According to the latest Casper FFG paper ;

The genesis block is a checkpoint, and every block whose height in the block tree (or block number) is an exact multiple of 100 is also a checkpoint.

However, some discussions seem to indicate that this number is not set in stone (1). I would suggest updating this section to a more up to date value or simply remove the specific value as this is more of an implementation detail.

According to latest version of the Casper FFG paper ;

Once validator ν leaves the validator set, the validator’s public key is forever forbidden from rejoining the validator set. This removes the need to handle multiple start/end dynasties for a single identifier.

However, according to the most recent implementation casper contract, validator's information are deleted after they withdraw their deposit, allowing them to deposit once again. The above cited section seems to be an implementation specification that could be omitted from the paper.

https://github.com/ethereum/research/tree/master/ssz_hashable_list

Not certified to be exactly up to spec, but it does pass basic tests. Ensures that updates to an SSZ hashable list can be done in O(log(n)) time, and supports logic for append and pop.

Do you have a bandersmatch solution in the verkle tree? I can't use it in the source code.thank you very much！
”from bandersnatch import Point, Scalar“ in research/verkle_trie_eip/verkle_trie.py