ExternalVendorCode/corda
1
0
Fork 0
mirror of https://github.com/corda/corda.git synced 2025-06-17 22:58:19 +00:00
Code Issues Actions 2 Packages Projects Releases Wiki Activity

CORDA-1894 Remove if condition from service hub that prevents vault logic executing. (#3773)

Browse Source
This commit is contained in:
Rick Parker
2018-08-13 14:17:03 +01:00
committed by GitHub
parent 0746b1f927
commit 0a18979307
1 changed files with 35 additions and 37 deletions
Download Patch File Download Diff File Expand all files Collapse all files

72
node/src/main/kotlin/net/corda/node/services/api/ServiceHubInternal.kt
View File

@ -65,43 +65,41 @@ interface ServiceHubInternal : ServiceHub {
log.warn("Transactions recorded from outside of a state machine") log.warn("Transactions recorded from outside of a state machine")
} }
if (statesToRecord != StatesToRecord.NONE) { // When the user has requested StatesToRecord.ALL we may end up recording and relationally mapping states
// When the user has requested StatesToRecord.ALL we may end up recording and relationally mapping states // that do not involve us and that we cannot sign for. This will break coin selection and thus a warning
// that do not involve us and that we cannot sign for. This will break coin selection and thus a warning // is present in the documentation for this feature (see the "Observer nodes" tutorial on docs.corda.net).
// is present in the documentation for this feature (see the "Observer nodes" tutorial on docs.corda.net). //
// // The reason for this is three-fold:
// The reason for this is three-fold: //
// // 1) We are putting in place the observer mode feature relatively quickly to meet specific customer
// 1) We are putting in place the observer mode feature relatively quickly to meet specific customer // launch target dates.
// launch target dates. //
// // 2) The right design for vaults which mix observations and relevant states isn't entirely clear yet.
// 2) The right design for vaults which mix observations and relevant states isn't entirely clear yet. //
// // 3) If we get the design wrong it could create security problems and business confusions.
// 3) If we get the design wrong it could create security problems and business confusions. //
// // Back in the bitcoinj days I did add support for "watching addresses" to the wallet code, which is the
// Back in the bitcoinj days I did add support for "watching addresses" to the wallet code, which is the // Bitcoin equivalent of observer nodes:
// Bitcoin equivalent of observer nodes: //
// // https://bitcoinj.github.io/working-with-the-wallet#watching-wallets
// https://bitcoinj.github.io/working-with-the-wallet#watching-wallets //
// // The ability to have a wallet containing both irrelevant and relevant states complicated everything quite
// The ability to have a wallet containing both irrelevant and relevant states complicated everything quite // dramatically, even methods as basic as the getBalance() API which required additional modes to let you
// dramatically, even methods as basic as the getBalance() API which required additional modes to let you // query "balance I can spend" vs "balance I am observing". In the end it might have been better to just
// query "balance I can spend" vs "balance I am observing". In the end it might have been better to just // require the user to create an entirely separate wallet for observing with.
// require the user to create an entirely separate wallet for observing with. //
// // In Corda we don't support a single node having multiple vaults (at the time of writing), and it's not
// In Corda we don't support a single node having multiple vaults (at the time of writing), and it's not // clear that's the right way to go: perhaps adding an "origin" column to the VAULT_STATES table is a better
// clear that's the right way to go: perhaps adding an "origin" column to the VAULT_STATES table is a better // solution. Then you could select subsets of states depending on where the report came from.
// solution. Then you could select subsets of states depending on where the report came from. //
// // The risk of doing this is that apps/developers may use 'canned SQL queries' not written by us that forget
// The risk of doing this is that apps/developers may use 'canned SQL queries' not written by us that forget // to add a WHERE clause for the origin column. Those queries will seem to work most of the time until
// to add a WHERE clause for the origin column. Those queries will seem to work most of the time until // they're run on an observer node and mix in irrelevant data. In the worst case this may result in
// they're run on an observer node and mix in irrelevant data. In the worst case this may result in // erroneous data being reported to the user, which could cause security problems.
// erroneous data being reported to the user, which could cause security problems. //
// // Because the primary use case for recording irrelevant states is observer/regulator nodes, who are unlikely
// Because the primary use case for recording irrelevant states is observer/regulator nodes, who are unlikely // to make writes to the ledger very often or at all, we choose to punt this issue for the time being.
// to make writes to the ledger very often or at all, we choose to punt this issue for the time being. vaultService.notifyAll(statesToRecord, recordedTransactions.map { it.coreTransaction })
vaultService.notifyAll(statesToRecord, recordedTransactions.map { it.coreTransaction })
}
} }
} }
} }