#12712 Internal Audit Built into Polkadot Protocol - Parallel Finance Case Study
Hey All,
In the old Polkadot protocol their used to be fisherman, which was subsequently taken out. As of right now, the protocol relies on probabilistic economic backing and then a subsequent “audit” by other validators before the block becomes deterministically final. While this is secure, there could be other ways to make this more secure.
Has their been any considerations to use what I would coin “Internal Audit” to the protocol. This would be something similar to fisherman; however, the fisherman in this case would be a predefined validator that has been specifically designated by the project team. Obviously they could opt out by just not using the functionality if it were added. You could almost think of this as adding an outside validator or if we are going with computer terminology of JAM, adding “external” hardware to the computer.
The block from the blockchain would route based on predefined logic to a validator outside of the Core set (this is in addition to the coreset as well) for validation. If the internal auditor rejected the block, it would in essence be tossed out. The internal auditor could be the project team directly or outsourced to a third party (like hiring outside internal auditors).
The validator could even reject what would be a “valid” block if needed. This would have been beneficial to Parallel Finance if they had an internal audit function that had been outsourced. That function could have in essence blocked any movement of funds from the chain.
This functionality would likely only be used by blockchains that are opting out of full decentralization by keeping administrative keys to their blockchain.
Just throwing out some thoughts that could even make Polkadot even more resilient.
If the functionality were to be introduced, the project team could end up creating availability issues if their validator did not work; however, it would be up to the project team to balance availability versus integrity risks. Further, you could also do an implementation that the block would be valid unless explicitly denied by the project team validator, which would keep availability risks the same while potentially reducing integrity risks.
Hey All,
In the old Polkadot protocol their used to be fisherman, which was subsequently taken out. As of right now, the protocol relies on probabilistic economic backing and then a subsequent “audit” by other validators before the block becomes deterministically final. While this is secure, there could be other ways to make this more secure.
Has their been any considerations to use what I would coin “Internal Audit” to the protocol. This would be something similar to fisherman; however, the fisherman in this case would be a predefined validator that has been specifically designated by the project team. Obviously they could opt out by just not using the functionality if it were added. You could almost think of this as adding an outside validator or if we are going with computer terminology of JAM, adding “external” hardware to the computer.
The block from the blockchain would route based on predefined logic to a validator outside of the Core set (this is in addition to the coreset as well) for validation. If the internal auditor rejected the block, it would in essence be tossed out. The internal auditor could be the project team directly or outsourced to a third party (like hiring outside internal auditors).
The validator could even reject what would be a “valid” block if needed. This would have been beneficial to Parallel Finance if they had an internal audit function that had been outsourced. That function could have in essence blocked any movement of funds from the chain.
This functionality would likely only be used by blockchains that are opting out of full decentralization by keeping administrative keys to their blockchain.
Just throwing out some thoughts that could even make Polkadot even more resilient.
If the functionality were to be introduced, the project team could end up creating availability issues if their validator did not work; however, it would be up to the project team to balance availability versus integrity risks. Further, you could also do an implementation that the block would be valid unless explicitly denied by the project team validator, which would keep availability risks the same while potentially reducing integrity risks.