DEV Community

Discussion on: 29 Essential Blockchain Interview Questions You Will Suck On

Collapse
 
jpantunes profile image
JP Antunes

This isn't very good, sorry Alex.

Q1 - a blockchain is a data structure that stores messages (blocks) sequentially using
the previous block's hash as a back link, so it resembles a linked list but backwards / “previous block hash" instead of next block pointer

A distributed ledger is an user level application that can use a blockchain to manage its data

Q2 - State, a state-transition function and messages

Q3 - that's an ok answer but ...

Q4 - ok

Q5 - the purpose of a node is to keep a local copy of the blockchain. it also allows for greater privacy when actually using a blockchain

Q6 - ok

Q7 - ok

Q8 - incorrect!!! Tokens and coins are not required to use a blockchain since any type of message can be sent and cause a change in state, it really depends on the state transition function used

Q9 - ok but... a merkle root is 32 bytes and it can represent anything from 0 to N bytes of data and not once is the relation to binary trees mentioned.

Q10 - ok but how about : data integrity, compression and efficiency

Q11 - nodes access the network directly and listen to messages, process those messages and brodcast new messages. there are different types of nodes in different blockchain implementations but these 3 are common among all of them

Q12 - the record of blocks in a chain is immutable because every new block relies on the previou block's hash. This means that due to how hashing works, any change to a historic block would break this chain. Ie, form the last block, you cannot travel back to the genesis block. There are cases where more than one chain can be fully valid and have different transaction histories which is where the consensus algorithm comes in.

Q13 - this is related to the proof of work algorithm and is a way of adjusting the block production times and ensure that enough work has been put into generating a new block that it is safe to trust it

Q14 - because this creates scarcity and is a driver for price growth. public blockchains are expensive to maintain and if the network token ("coin") isn't valued then no one will maintin it...

Q15 - ok but how about: it's just a regular app with access to a blockchain network and smart contracts. It can be just a React front end to a voting smart contract or it can be a whole business like Augur for instance.

Q16 - trapdoor functions are not visible or used in the blockchain, they are secp256k1 cryptographic primitives and at best it's used in a blockchain to derive an address from a private key. Mind you that hashing is not a trapdoor function because its not reversible while deriving a priv key from a pub key can be done (if one has unlimited computing power)

Q17 - no, no and no. changes in state can happen without tokens or coins being involved. see a multi-sig wallet for instance.. it collect signatures before any coin is used!

Q18 - true for full nodes but doesn't explain how light nodes can also trust the chain of blocks they are following

Q19 - ok

Q20 - a smart contract is a set of instructions or algorithms that are hosted and ran in a blockchain. they are not trustwhorty in and on themselves, ie a bad actor can make a bad contract that does bad things

Q21 - ok but...

Q22 - ok but...

Q23 - :-( this is bad! not only does it misrepresent difiiculty target calculation but also does a terrible job with the nonce!!!

Q24 - :-( this is worse. PoS means that the state transition function is controled by a semi-closed group who must put a large amount of money at stake in order to be trusted to produce or validate blocks. Modern PoS designs include the concept of slashing which is like a penalty applied to a validator who accepts bad blocks or bad transactions so it would be like a PoW miner having their rig explode.

Q25 - ok but... PoW is fully trustless and PoS introduces some trust requirements, it nothing more then in the staking contract not having any bugs

Q26 - it's all and every transaction that happens outside a blockchain but whose proof (like a link to a receipt or its hash) is stored on-chain

Q27 - ok but.. you can also rewrite blockchain history (ie: long range attack)

Q28 - ok

Q29 - ok but..