I have just started learning about Blockchain and I am still new to most of the concepts. So please help me out with this. I have read in my class notes that SHA-256 algorithm has a block size of 512 bits, and Bitcoin uses this algorithm too. But when I researched online it says that Bitcoin has a block size of 1MB.
What am I missing over here?
So the concept of "Block" is different in the context of a hash function and the Bitcoin blockchain.
In the context of hash functions, SHA256 processes input data in chunks, and the size limit of each data chunk is called block size. In the case of SHA256, the block/data chunk size limit is 512bits.
In the context of Bitcoin, there's a data structure called "block". Each block contains metadata info and a group of transactions. The hash of block i is packed into the metadata of block i+1, which constructs a connection between these 2 blocks, thus it's called Blockchain. It's like a chain of blocks with each block containing the hash of its previous block. The size limit of each block, in the context of Bitcoin, is 1MB. It limits how many transactions can be packed into a single block because the size of the block matters for the decentralization of the blockchain. Lower the size of the block, lower the requirement for the network nodes' bandwidth and thus more nodes can join the network.
If you want to learn more comprehensively about Bitcoin, this is the go to material I would recommend: https://github.com/bitcoinbook/bitcoinbook
Related
For a newly allocated mbuf, the area at which the data begins in the message buffer is RTE_PKTMBUF_HEADROOM bytes after the beginning of the buffer, which is cache aligned.
As far as I know, the headroom does not contain any data. So I wonder why there should be a headroom in the mbuf？In addition, the default size of HEADROOM is 128B.I've tried setting the HEADROOM size to something bigger, like 5120B, and it doesn't affect performance. So I want to know what is the purpose of the existence of the Headroom, and is there any theoretical limit to the size of the Headroom?
A DPDK mbuf's headroom is suited for prepending extra data (typically, metadata) to the packet data. Its use cases are PMD-specific. For example, virtio PMD stores struct virtio_net_hdr in it. Other drivers may use this for offload results: checksum validity status, packet classification, hash values, you name it.
As for the upper limit, it depends on the mbuf object's maximum size and on the minimum packet data room, which, in turn, might be PMD-specific. For the majority of use cases, it's OK to just rely on default size.
After reading Grokking Bitcoin I now have a broad idea of how Bitcoin works, but I still have a doubt that, generally, how a blockchain-based system can guarantee the immutability of a random block? I know every block has a stored hash value of the content of the previous block plus some nonce.
Let's say this blockchain(for simplicity, we use a linked-list style rather than a Merkle tree style) has 1000 blocks, and a hacker just changed the content inside of the 10-th block. Of course, if we recompute the hash of this 10-th block and compare it with the hash stored inside of the 11th block, it will be different, most probably.
My question is, should a blockchain-based system periodically check the hash inside of every block to detect if the content of a block is changed? In this case, if the system does not have a function to periodically recompute the hash of the 10-th block, it will not be able to detect the change, right? In other words, my question is how a blockchain-based system detects the change of a block?
Thanks
When you change the content of the 10th block you have to find the hash to meet the difficulty for that block. This is called "mining" and it takes time/energy. When you finally found the hash value for that block you can propagate your new block to the blockchain to all the other nodes.
However, they will ignore this block which would create a new branch of the blockchain at the 9th block because it is 991 blocks behind the current blockchain (that's about 7 days behind in the blockchain). The miners will work only on the longest chain for new blocks, not on the most recent received chain. So, your new 10th block will not be saved or used at all. Your effort in calculating the hash is wasted. Furthermore, the original 10th block is still inside the blockchain known by every other node and it has not been changed. You have just mined a different 10th block no other node cares about.
Im trying to understand hardware Caches. I have a slight idea, but i would like to ask on here whether my understanding is correct or not.
So i understand that there are 3 types of cache mapping, direct, full associative and set associative.
I would like to know is the type of mapping implemented with logic gates in hardware and specific to say some computer system and in order to change the mapping, one would be required to changed the electrical connections?
My current understanding is that in RAM, there exists a memory address to refer to each block of memory. Within a block contains words, each words contain a number of bytes. We can represent the number of options with number of bits.
So for example, 4096 memory locations, each memory location contains 16 bytes. If we were to refer to each byte then 2^12*2^4 = 2^16
16 bit memory address would be required to refer to each byte.
The cache also has a memory address, valid bit, tag, and some data capable of storing a block of main memory of n words and thus m bytes. Where m = n*i (bytes per word)
For an example, direct mapping
1 block of main memory can only be at one particular memory location in cache. When the CPU requests for some data using a 16bit memory location of RAM, it checks for cache first.
How does it know that this particular 16bit memory address can only be in a few places?
My thoughts are, there could be some electrical connection between every RAM address to a cache address. The 16bit address could then be split into parts, for example only compare the left 8bits with every cache memory address, then if match compare the byte bits, then tag bits then valid bit
Is my understanding correct? Thank you!
Really do appreciate if someone read this long post
You may want to read 3.3.1 Associativity in What Every Programmer Should Know About Memory from Ulrich Drepper.
https://people.freebsd.org/~lstewart/articles/cpumemory.pdf#subsubsection.3.3.1
The title is a little bit catchy, but it explains everything you ask in detail.
In short:
the problem of caches is the number of comparisons. If your cache holds 100 blocks, you need to perform 100 comparisons in one cycle. You can reduce this number with the introduction of sets. if A specific memory-region can only be placed in slot 1-10, you reduce the number of comparisons to 10.
The sets are addressed by an additional bit-field inside the memory-address called index.
So for instance your 16 Bit (from your example) could be splitted into:
[15:6] block-address; stored in the `cache` as the `tag` to identify the block
[5:4] index-bits; 2Bit-->4 sets
[3:0] block-offset; byte position inside the block
so the choice of the method depends on the availability of hardware-resources and the access-time you want to archive. Its pretty much hardwired, since you want to reduce the comparison-logic.
There are few mapping functions used for map cache lines with main memory
Direct Mapping
Associative Mapping
Set-Associative Mapping
you have to have an slight idea about these three mapping functions
I have a sample blockchain application on which I have created a several blocks with the help of "invoke" transactions.
1) The blockchain theory suggests that each block will have a field called "previousBlockHash" containing the hash value of previous block in blockchain. Now when I am comparing the fields "stateHash" of previous block(Block #2) Vs "previousBlockHash" of current block(Block #3), they both appear to be very different. Should they be equal?
2) Can one blockchain block contain multiple "invoke" transactions?**
There is a difference between StateHash and BlockHash, where state hash is simply a hash of the data inside given block and the block hash computed as following:
A block hash is calculated by hashing over the concatenated ASN.1 encoded bytes of: the block number, previous block hash, and current block data hash. It's the chain of the block hashs that guarantees the immutability of the ledger
Block usually will be comprised of several ordered invoke transactions. So to your question - yes it can contain more than one transaction inside.
Get-CacheStatistics command shows that any small object (even 1 Integer) takes at least 1024 bytes in cache memory. Is it correct and is there any way to adjust AppCache to handle memory more efficient for small objects?
In fact, there is an error in your understandings.
It's true taht objects are stored in the cache in a serialized form but there are other internal data structures that require memory in the cache : key, duration, named cache, regions, tags, notifications, ... take a look on capacity guide.
There is no way to manage internal cache data structure.