Abstract: An exemplary method includes a proximity detection system that accesses information associated with a virtual location marker positioned in relation to a geographic area. The information defines a location-based field of view (“LFOV”) that extends directionally from the virtual location marker. The proximity detection system further tracks a location of a mobile computing device at the geographic area and determines, based on the information associated with the virtual location marker and the location of the mobile computing device, that the mobile computing device has entered the LFOV that extends directionally from the virtual location marker.

Abstract: An exemplary method includes a proximity detection system that accesses information associated with a virtual location marker positioned in relation to a geographic area. The information defines a location-based field of view (“LFOV”) that extends directionally from the virtual location marker. The proximity detection system further tracks a location of a mobile computing device at the geographic area and determines, based on the information associated with the virtual location marker and the location of the mobile computing device, that the mobile computing device has entered the LFOV that extends directionally from the virtual location marker.

Abstract: Multi-node resiliency may provide two or more points in a blockchain architecture from which a restarted peer can synchronize its local ledger with local ledgers of other peers that collectively form a distributed ledger. Storage-based resiliency may include providing storage that is separate from the nodes on which peers execute, and configuring a peer to store a copy of a synchronized local ledger to storage prior to restart, and synchronizing a new instance of a local ledger with the synchronized copy from storage upon restarting the peer. Peer-based resiliency may include obtaining a synchronized local ledger or genesis block from a first peer after restarting a second peer. Another point of resiliency may be provided by an orderer cluster that distributes blocks to the peers for committing to their local ledger. A peer may access obtain a synchronized ledger or genesis block from the orderer cluster upon restart.

Abstract: Multi-node resiliency may provide two or more points in a blockchain architecture from which a restarted peer can synchronize its local ledger with local ledgers of other peers that collectively form a distributed ledger. Storage-based resiliency may include providing storage that is separate from the nodes on which peers execute, and configuring a peer to store a copy of a synchronized local ledger to storage prior to restart, and synchronizing a new instance of a local ledger with the synchronized copy from storage upon restarting the peer. Peer-based resiliency may include obtaining a synchronized local ledger or genesis block from a first peer after restarting a second peer. Another point of resiliency may be provided by an orderer cluster that distributes blocks to the peers for committing to their local ledger. A peer may access obtain a synchronized ledger or genesis block from the orderer cluster upon restart.

Abstract: Multi-node resiliency may provide two or more points in a blockchain architecture from which a restarted peer can synchronize its local ledger with local ledgers of other peers that collectively form a distributed ledger. Storage-based resiliency may include providing storage that is separate from the nodes on which peers execute, and configuring a peer to store a copy of a synchronized local ledger to storage prior to restart, and synchronizing a new instance of a local ledger with the synchronized copy from storage upon restarting the peer. Peer-based resiliency may include obtaining a synchronized local ledger or genesis block from a first peer after restarting a second peer. Another point of resiliency may be provided by an orderer cluster that distributes blocks to the peers for committing to their local ledger. A peer may access obtain a synchronized ledger or genesis block from the orderer cluster upon restart.

Abstract: Multi-node resiliency may provide two or more points in a blockchain architecture from which a restarted peer can synchronize its local ledger with local ledgers of other peers that collectively form a distributed ledger. Storage-based resiliency may include providing storage that is separate from the nodes on which peers execute, and configuring a peer to store a copy of a synchronized local ledger to storage prior to restart, and synchronizing a new instance of a local ledger with the synchronized copy from storage upon restarting the peer. Peer-based resiliency may include obtaining a synchronized local ledger or genesis block from a first peer after restarting a second peer. Another point of resiliency may be provided by an orderer cluster that distributes blocks to the peers for committing to their local ledger. A peer may access obtain a synchronized ledger or genesis block from the orderer cluster upon restart.