I'm learning about blockchains and one topic I don't quite understand is what happens when you tamper with a block on the chain. What happens to what comes after it?
I get the whole concept of proof-of-work and the hash of both the block itself and the previous one. Mainly, what I don't quite get is once it is proven that a certain block was altered and tampered with due to it no longer connecting to the chain, what happens to the rest that comes after this block?
I know there are two main scenarios that are possible:
The block tampered with is the newest block;
The tampered block is in the middle of the chain;
If it's the newest block, wouldn't the ones that come after it actually approve that information and the data inside the tampered one pass since the hash of the previous block would actually be the one from the tampered? And what if the tampering happened after that block is already on the chain? Would the whole system just cracks and that copy of the blockchain be unconsidered?
Because blockchains work as a system where there's not only one ledger, but several, I get that a block to be added has to pass through a rigorous proof-of-work procedure and if you temper with a block in the middle of the chain, even though you succeeded to mine all following blocks again it still wouldn't work because the several other ledgers will say that this action is not legitimate. Hence, I ask again; where does this block go? Does it just disappear?
Moreover, what stops me from creating a block with fake information, let's suppose that it says I received 5 BTC and I crack the proof-of-work and succeed in finding a nonce that works; how does the system later understand that the information I provided is fake since I'd broadcast to all ledgers that I cracked the nonce and my block is added to the chain?
I'd love it if someone could go over this, it would really help me a lot.
Related
I'm kind of a starter here in the blockchain ecosystem, and I have some questions, but one really seems to bother me since is kind of contradictory.
When you generate a block, each block contains the Header, that contains the previous hash, and hash representation of the current block data, and some other things.
But if every block references the previous block with the hash that was generated with the current data of that block, and every block is immutable...
How can every block in a blockchain can have every other block data if the block is immutable, and also if you change the data, the identity hash of the block immediately changes?
And another one...
Which is the detailed process that happens when there is a transaction available, and how does it incorporates to the blockchain?
Maybe this questions seems kind of dumb to some, but I've been searching and no articles or videos have solved my doubts.
Thanks to all, and have a nice day :)
Every block on the blockchain does not have every other block's data. Actually you might have confused it with Every node (A node is an instance connected to p2p network of blockchain) on blockchain has all the blocks written to the blockchain so far.
So the statement
Every block in a blockchain can have every other block data.
is not true. A block only has data that was added to it at the time of creation after that no data can be added or removed from it.
Now towards your 2nd question
Which is the detailed process that happens when there is a transaction available, and how does it incorporates to the blockchain?
Lets say A transfers B 1 BTC now first of all in order to submit the transaction you have to be connected to blockchain node or a service that is connected to blockchain (bitcoin blockchain in this case) node.
Normally the wallet apps we use to transfer crypto are connected to blockchain node and post our transactions for us.
Once the transaction is given to a node to process initially it is validated and added to what is called mempool which is essentially a place where all the transactions that are yet to be added in blocks live. Mostly nodes have dedicated some space for mempool. Now nodes pick up transaction from mempool (prioritising the one's with higher fee as they get to keep the fee) and add it in a block. This block is called "candidate block".
Nodes start minning candidate block and if they are lucky enough to mine it first the block is broadcasted to the whole network and everyone adds this block to their chain and start minning next block repeating the same process as above.
The Above process is mainly for bitcoin blockchain but other blockchain all of similar processes.
For beginners instead of going through articles and youtube videos i would recommend studying these books to develop a thorough understanding of underlying architecture. There are mainly two type of blockchain (with in crypto eco system) UTXO Based (old ones mainly Bitcoin and its derivaties LTC Zcash DASH etc) and Account Based (New ones Ethereum BNB etc).
For UTXO Based Blockchain.
https://www.oreilly.com/library/view/mastering-bitcoin/9781491902639/ch01.html.
For Account Based Blockchain.
https://www.amazon.com/Mastering-Ethereum-Building-Smart-Contracts/dp/1491971940
One key difference often highlighted between Events and Commands in EDA is as follows:
Events are something which has happened
Commands are requests for something which might happen
What I can't understand is why implementations often use both of these together, when one always seems to be redundant? For example when we need to check if a customer has enough credit in order to complete an order, we can achieve this purely with events:
There are no commands on this diagram whatsoever. But in this article, it's suggested there are commands created in addition to the events behind the scenes:
What is the benefit of also including Commands here, doesn't it just add complexity? And which of the two is the Customer Service actually subscribing to, the CreatePendingOrderCommand, or the OrderCreatedEvent? Surely only one of these is acted upon by the Customer Service?
What I can't understand is why implementations often use both of these together, when one always seems to be redundant?
In general, they aren't quite the same thing; it's only in the simple cases that the information is redundant.
"Commands" a something akin to proposals: they are messages that we send toward some authority to effect some change. "Events" are messages being sent from some authority.
Commands deliver new information to an authority. Events describe how information has been integrated with what was known before.
Events describe information that will be available when processing future commands - the information is durable; commands are transient.
Commands are often generated from a stale non-authoritive snapshot of some information (a report, or a "view"). Events are reflections of the state of the authority itself.
Events fan out from an authority; we know the sender, but not necessarily the receiver. Commands fan into an authority, we know the receiver, but not necessarily the sender.
It is pretty squishy. We are making copies of a data structure, and at some point our perspective shifts, and even though the source data structure is an event, the copy is a command.
Think subscription: the system is going to copy a data structure from my output stream (an event) to your input stream (a command).
My suggestion: it's all just "messages". Allow yourself to leave it there until you have more laps under your belt.
I would say
"A command can emit any number of events."
"Commands can be rejected."
"Events have happened."
We are using Lagom for developing our set of microservices. The trick here is that although we are using event sourcing and persisting events into cassandra but we have to store the data in one of the graph DB as well since it will be the one that will be serving most of the queries because of the use case.
As per the Lagom's documentation, all the insertion into Graph database(or any other database) has to be done in ReadSideProcecssor after the command handler persist the events into cassandra as followed by philosophy of CQRS.
Now here is the problem which we are facing. We believe that the ReadSideProcecssor is a listener which gets triggered after the events are generated and persisted. What we want is we could return the response back from the ReadSideProcecssor to the ServiceImpl. Example when a user is added to the system, the unique id generated by the graph has to be returned as one of the response headers. How that can be achieved in Lagom since the response is constructed from setCommandHandler and not the ReadSideProcessor.
Also, we need to make sure that if due to any error at graph side, the API should notify the client that the request has failed but again exceptions occuring in ReadSideProcessor are not propagated to either PersistentEntity or ServiceImpl class. How can that be achieved as well?
Any helps are much appreciated.
The read side processor is not a listener that is attached to the command - it is actually completely disconnected from the persistent entity, it may be running on a different node, at a different time, perhaps even years in the future if you add a new read side processor that first comes up to speed with all the old events in history. If the read side processor were connected synchronously to the command, then it would not be CQRS, there would not be segregation between the command and the query side.
Read side processors essentially poll the database for new events, processing them as they detect them. You can add a new read side processor at any time, and it will get all events from all of history, not just the new ones that are added, this is one of the great things about event sourcing, you don't need to anticipate all your query needs from the start, you can add them as the query need comes.
To further explain why you don't want a connection between the two - what happens if the event persist succeeds, but the update on the graph db fails? Perhaps the graph db is crashed. Does the command have to retry? Does the event have to be deleted? What happens if the node doing the update itself crashes before it has an opportunity to fix the problem? Now your read side is in an inconsistent state from your entities. Connecting them leads to inconsistency in many failure scenarios - for example, like when you update your address with a utility company, and but your bills still go to the old address, and you contact them, and they say "yes, your new address is updated in our system", but they still go to the old address - that's the sort of terrible user experience that you are signing your users up for if you try to connect your read side and write side together. Disconnecting allows Lagom to ensure consistency between the events you have emitted on the write side, and the consumption of them on the read side.
So to address your specific concerns: ID generation should be done on the write side, or, if a subsequent ID is generated on the read side, it should also provide a way of mapping the IDs on the write side to the read side ID. And as for handling errors on the read side - all validation should be done on the write side - the write side should ensure that it never emits an event that is invalid.
Now if the read side processor encounters something that is invalid, then it has two options. One option is it could fail. In many cases, this is a good option, since if something is invalid or inconsistent, then it's likely that either you have a bug or some form of corruption. What you don't want to do is continue processing as if everything is happy, since that might make the data corruption or inconsistency even worse. Instead the read side processor stops, your monitoring should then detect the error, and you can go in and work out either what the bug is or fix the corruption. Of course, there are downsides to doing this, your read side will start lagging behind the write side while it's unable to process new events. But that's also an advantage of CQRS - the write side is able to continue working, continue enforcing consistency, etc, the failure is just isolated to the read side, and only in updating the read side. Instead of your whole system going down and refusing to accept new requests due to this bug, it's isolated to just where the problem is.
The other option that the read side has is it can store the error somewhere - eg, store the event in a dead letter table, or raise some sort of trouble ticket, and then continue processing. This way, you can go and fix the event after the fact. This ensures greater availability, but does come at the risk that if that event that it failed to process was important to the processing of subsequent events, you've potentially just got yourself into a bigger mess.
Now this does introduce specific constraints on what you can and can't do, but I can't really anticipate those without specific knowledge of your use case to know how to address them. A common constraint is set validation - for example, how do you ensure that email addresses are unique to a single user in your system? Greg Young (the CQRS guy) wrote this blog post about those types of problems:
http://codebetter.com/gregyoung/2010/08/12/eventual-consistency-and-set-validation/
We are currently working on a FIX connection, whereby data that should only be validated can be marked. It has been decided to mark this data with a specific TargetSubID. But that implies a new session.
Let's say we send the messages to the session FIX.4.4:S->T. If we then get a message that should only be validated with TargetSubID V, this implies the session FIX.4.4:S->T/V. If this Session is not configured, we get the error
Unknown session: FIX.4.4:S->T/V
and if we explicitly configure this session next to the other, there is the error
quickfix.Session – [FIX/Session] Disconnecting: Encountered END_OF_STREAM
what, as bhageera says, is that you log in with the same credentials.
(...) the counterparty I was connecting to allows only 1 connection
per user/password (i.e. session with those credentials) at a time.
I'm not a FIX expert, but I'm wondering if the TargetSubID is not just being misused here. If not, I would like to know how to do that. We develop the FIX client with camel-quickfix.
It depends a lot on what you system is like and what you want to achieve in the end.
Usually the dimensions to assess are:
maximising the flexibility
minimising the amount of additional logic required to support the testing
minimising the risk of bad things happening on accidental connection from a test to a prod environment (may happen, despite what you might think).
Speaking for myself, I would not use tags potentially involved in the sesson/routing behavior for testing unless all I need is routing features and my system reliably behaves the way I expect (probably not your case).
Instead I would consider one of these:
pick something from a user defined range (5000-9999)
use one of symbology tags (say Symbol(55)) corrupted in some reversible way (say "TEST_VOD.L" in the tag 55 instead of "VOD.L")
A tag from a custom range would give a lot of flexibility, a corrupted symbology tag would make sure a test order would bounce if sent to prod by accident.
For either solution you may potentially need a tag-based routing and transformation layer. Both are done in couple of hours in generic form if you are using something Java-based (I'd look towards javax.scripting / Nashorn).
It's up to the counterparties - sometimes Sender/TargetSubID are considered part of the unique connection, sometimes they distinguish messages on one connection.
Does your library have a configuration option to exclude the sub IDs from the connection lookups? e.g. in QuickFix you can set the SessionQualifier.
in short my questions are:
Is there anything built-in into drools that allows/facilitates detection of endless loops?
Is there a way to programmatically halt sessions (e.g. for the case of a detected endless loop)?
More details:
I'm planning to have drools (6.2 or higher) run within a server/platform where users will create and execute their own rules. One of the issues I'm facing is that carelessly/faulty rule design can easily result in endless loops (whether its just a forgotten "no-loop true" statement or the more complex rule1 triggers rule2 triggers rule3 (re)triggers rule1 circles that lead to endless loops.
If this happens, drools basically slows down my server/platform to a halt.
I'm currently looking into how to detect and/or terminate sessions that run in an endless loop.
Now as a (seemingly) endless loop is nothing that is per-se invalid or in certain cases maybe even desired I can imagine that there is not a lot of built-in detection mechanism for this case (if any). But as I am not an expert I'd be happy to know if there is anything built-in to detect endless loops?
In my use case I would be ok to determine a session as "endlessly looped" based on a threshold of how often any rule might have been activated.
As I understand I could use maybe AgendaEventListeners that keep track of how often any rule has been fired and if a threshold is met either insert a control fact or somehow trigger a rule that contains the drools.halt() for this session.
I wonder (and couldn't find a lot of details) if it is possible to programmatically halt/terminate sessions.
I've only come across a fireUntilHalt() method but that didn't seem like the way to go (or I didnt understand it really).
Also, at this point I was only planning to use stateless session (but if it's well encapsulated I could also work with stateful sessions if that makes my goal easier to achieve).
Any answers/ideas/feedback to my initial approach is highly welcome :)
Thanks!
A fundamental breaking point of any RBS implementation is created where the design lets "users create and design their own rules". I don't know why some marketing hype opens the door for non-programmers to write what is program code, without any safeguarding.
Detecting whether a session halts is theoretically impossible. Google "Halting problem".
For certain contexts you might come up with a limit of the number of rules that might be executed at most or something similar. And you can use listeners to count and raise an exception, etc etc.
Basically you have very bad cards once you succumb to the execution of untested code created by amateurs.